Home

Crafting a Business Oriented Developer Portfolio that Stands Out

edit ✏️

There are many reasons to create a portfolio as a software developer. You might be new to the career and need a way to represent your capabilities. You might have worked exclusively at companies that firewall your work examples behind non-disclosure agreements (NDAs) that protect their intellectual property. Maybe you're a freelancer or consultant and need to showcase your skills for potential clients.

You might just like building examples and showing them to folks. These are all excellent reasons to create a developer portfolio!

What is a developer portfolio?

Portfolios are a long-standing tradition for artists and designers as a way to showcase their work and capabilities to prospective employers or clients.

A portfolio contains representative examples of your skills as they relate to your craft. These examples can be created specifically as "portfolio pieces" or extracted from on-the-job projects when possible.

Why have a portfolio as a developer?

As a developer, we have the potential to create a portfolio that demonstrates what we are capable of, including:

Developer portfolios don't have to focus on visual design

When looking at portfolios, it can be overwhelming because they often focus on the visual design aspects of a traditional artist or designer's portfolio. This is fantastic if you have those skills, but it's also important to note that if you are a programmer that produces functionality via code the visual design aspects aren't required.

You can create a compelling portfolio that is clean, minimal, and doesn't focus on visual design if that isn't in your desired skillset.

What should be in my portfolio

This is the million dollar question, and the answer varies by context. There's no silver bullets as far as portfolio contents or any way to guarantee that your portfolio will land you a specific job.

With that in mind, consider focusing your portfolio work on projects that represent the kind of work you'd like to do and the type of work they do at places you'd like to work (or clients you'd like to land).

If you'd really hate working on a banking application, don't put effort into developing a banking application for your portfolio!

This might seem obvious, but it's worth stating explicity.

There are a lot of common apps that are likely not going to be standouts for your portfolio. The todo application is an excellent common vehicle for learning languages and frameworks, but unless you've got a unique take on it the todo app is probably not a great fit for a developer portfolio.

What these all have in common is that they are practical and business oriented. It's not to say that your portfolio can't have fun, whimsical aspects. A "hot or not" for cats, or whatever ideas make you chuckle, but if the outcome you are hoping to achieve is a good/better job as a software developer then it makes sense to focus your portfolio on business class applications.

Keep it small. Instead of building a full Jira clone, pick an aspect of Jira and build that. If it's interesting, iterate and expand, but start small so that it's achievable in a reasonable amount of time.

Trying to "go big" can make the wins too few and far between, and this is a long-game where you need to rack up small wins to keep going.

My observation is that people like to over-scope a project and get defeated by the sheer volume.

Keep it simple. Keep it small.

Portfolio applications don't need to innovate

The applications you build for your portfolio don't need to be unique innovations. These developer portfolio applications aren't meant to showcase your ability to craft a new startup from scratch!

They certainly could, but if that was the scope and result we should have a different discussion related to founding a startup or bootstrapping a business (which is a wonderful discussion).

Your developer portfolio can be clean, minimal, and practical. You can clone existing business applications, and don't need to spend a lot of time brainstorming clever ideas for what to build. Start with practical real-world everyday plain old web applications that you actually use and understand.

Demonstrate the process not just the result

In a very practical way it's essential to communicate and collaborate when you are working as a software developer. It can be challenging, particularly if you are working on your portfolio solo, to accomplish this.

Do not spring a fuckin' "TADA 🎉!1!" at the end of a project with just the final result.

Real-world business is about mitigating risk, communication, iteration and process, and it's 100% possible to achieve this even when working on your developer portfolio by yourself.

Create your own space on the internet

If you haven't already, craft your website. Keep it simple. It should support markdown and be as easy as possible to post to.

Here's a quick talk that I gave at CascadiaJS about creating a simple space for yourself on the internet.

https://www.youtube.com/embed/wOnvJQ9nPSY

There are other sites that you could "blog on" but they are absolutely not as great as having your own space in your own domain.

My favorite way to look at my personal space on the internet is as a Digital Garden.

a small wilted plant in a pot

Your website is also part of your portfolio!

It's a marketing site, and as a developer you are a business.

As a developer, you are a business.

Act accordingly, if you agree.

Plan what you are going to build

After over 20 years developing software there's one constant:

Every business and organization I've worked with or observed has some sort of layered (often broken 😅) process. This is critical to understand.

It's often called "agile" or any other number of names, sometimes Agile™ or SCRUM. There are Project Management Professionals and Certified Scrum Masters and a deep rabbit whole of other named/branded processes. It's an entire career in and of itself.

You don't need to be a Certified Scrum Master or follow a strict agile process.

You do need to approach your projects in a way that specifies the work you will do, how you will do it, and the concrete steps that get you from point a to point b.

Readme Driven Development

A good README goes a long way. This is a documentation first approach to development.

🔥 find a specific aspect of a piece of software that you use and write a README that describes how it works.

Tom Preston-Werner has a great article that introduced me to this idea of README driven development.

User Stories

A user story describes the work that is going to be done, who it is for, and what value it will provide.

"As a ____________ I want to ______________ so that _______________"

(this also applies to goats)

🔥 find an aspect of a piece of software you use and reverse engineer it into a set of user stories that you can use to rebuild it.

One of my favorite books about user stories is User Stories Applied by Mike Cohn.

Shape your work

After using a lot of processes the one that I currently find the most interesting and effective is Shape Up from Ryan Singer which describes the process and workflows they use at Basecamp to develop software.

Shape Up has roots in jobs-to-be-done theory and is a very practical and considered way to develop software.

It's more complex and intense than just writing a README or some user stories, but well worth your time and attention if you have or plan to have a career in software development.

Shape Up is a free online book that you can find here.

Show your work

At every step of the way you should be able to show your work. Write about your process. Write about what you are building. Show your napkin sketches. Discuss what you had to learn. Summarize your understanding.

🚨 If you don't fucking show your work nobody will know what you did and assume it was nothing.

In an office and on a team communication is arguably the most important aspect of the job. You need to simulate communication when you are working on your portfolio.

Show your work.

Learn in public.

Build in public.

Write about your work in progress.

Share it on Twitter.

Livestream it.

Record work sessions on Youtube.

Don't worry about polish or presentation. You can do that later!

Rinse and Repeat

Building a business oriented developer portfolio is something that can be achieved through consistent and focused effort over time.

Start small!

Iterate on small ideas if you want to create something bigger, but with smaller projects you can show a range of capabilities.

In business, process and communication are critical to success.

It's important that your portfolio demonstrates that you are able to understand and apply process as well as communicate your work in progress.

Do not hold your work for a big "TADA 🎉!1!".

Show your work. Share your work and demonstrate that you can communicate.

Don't worry about style or design if that's not part of your career focus. Keep it simple and usable, and it's fine.

Who has time for all this work?

"Holy fucking shit Joel, who has time for all this? Why should I have to do this just to get a job?"

Here's the facts as I have observed them....

This is all a lot of tedious, pain in the ass, time consuming unpaid work to build a really great developer portfolio.

It's hard, because it's hard.

The job is like that, and it's why software developers can command such high compensation after a relatively short time on the job.

Programming computers is not a ✨ magical talent ✨

This gig is a deeply layered, ultra high communication, endless contextual application of process.

From the business/hiring side of the table everything is about managing and mitigating risk. By demonstrating that you've got adequate technical skills, understand process, and willingly communicate effectively you are decreasing the risk involved in the decision to hire you.

You can't control the hiring managers decision, ultimately, but you do have the power and control to craft a world-class business oriented developer portfolio, show your process, and communicate it at every step of the way.

I'm looking forward to seeing what you create!