Always Be Building Part 2: What Do I Do Now?

Lessons from a career of building

NextPath Mag is created and curated by me, Robby Grodin, a Software Engineering leader with 15 years of industry experience and 700+ hours of coaching sessions completed. I run NextPath, a practice of the top SWE coaches in the industry.

If you’re interested in learning more about working with a career coach, check out our website.

A few weeks back I wrote a post (linked below) compelling you, dear readers, to keep on building even when you don’t want to. Even when you’re tired from non-technical work, drained by the interview process, or just plain uninspired.

Always Be Building

As a pretty persuasive person, I’m sure you read that and thought ok, cool, I can’t wait to build something Robby! But, now what? What do I build?

How Will We Build It?

The first thing I want you to explore is what mode of building you’d like to try. This might sound backwards but hear me out. When we step into the kitchen, we first decide if we want to cook, bake, or go straight to the drawer of takeout menus (oh my god I just realized that The Apps have even taken that from us 😭). When we plan a gym visit, we first decide if we want to focus on our legs, arms, core, or sit in the sauna for 10 minutes then go get a sweet treat as a reward. So we first need to figure out what muscles we want to build, what kitchen skills we want to hone, which will then inform what type of project we should take on.

I kind of think of this like video games, where there are different “modes”. Each one will help you build a different, but overlapping, set of skills. Here are a few of my favorite modes:

Time Trial

One skill that most engineers never get a chance to develop is the ability to build, from scratch, fast. If there’s one thing that I’ve found has helped me in my career it was fostering a prototyping mindset. This was a skill I developed early on, when I was lucky to be at the start of 3 projects in 3 years at one of the first companies I worked at. Each was in a different language/domain, and in general had very different needs- the consistent need being “get it done fast”.

After leaving that job, I was brought on as the first engineering lead at a corporate innovation lab. This job was, no joke, really fucking cool. I got to research and experiment with all the latest technology including AR/VR, IoT, autonomous vehicles, smart cities, and of course, blockchain (ok so not ALL of it was cool). The ability to GSD fast, not good, but fast, was key for every project as our products rarely made it to public use. And this exact ability is what was tested in my interview.

I was given a prompt to build a simple real-time web chatbot application that can be run locally. There was a requirement for a simple UI, a simple API, and persistent data. That was it. I could use whatever technology I want, whatever language, whatever frameworks, etc. I was handed a Macbook Pro with a new system install on it and was told I had 2 hours while the proctor sat back, drank his coffee, and read the news.

When I had completed this task, I was worried that I didn’t do enough- my UI was unstyled vanilla Javascript, my API didn’t look too different from the Flask “Getting Started” tutorial, and I was storing data in SQLite. And I knew I was cooked when the interviewer put down his newspaper to test it out, and started laughing raucously.

It turns out that I had done exactly what he wanted, and the 30 seconds I took to make the server respond with one of four random messages such as “I am AI, bow down to me!” and “beep boop kill all humans” tickled his funny bones (this was in the 2010s so it was more humorous than it would be today).

So, the challenge is this:

• Sit down to build a full stack application in 2-3 hours, depending on the scope, from scratch.

• At the 2 hour mark, stop. You’re done for the day.

• The next day, open another blank repo and try it again. You’ll find that you’re moving faster as you’ve already solved stumbling blocks, and will discover other corners you can cut.

• Keep going until you’ve got it built in the allotted 2 hours.

What you’ll have learned is how to build fast by doing the bare minimum. You’ll also get muscle memory from doing it so many times- and don’t be discouraged if it takes you 5, 6, 7 sessions or more. Once you get it, you’ll get it.

Polyglot Test

“Ok but what language do I pick?”

You can spend weeks trying to choose the perfect stack for an application, but in the real world you have to basically eenie-meenie-minie-moe and pray for the best. This is because, not only do you never have enough time to do anything, but the requirements are going to change by the time you merge your first PR (and then again every PR after).

I’ll never forget the call I had with my CTO 3 weeks into a new role at a new company. Not a company that was new to me, but one that had literally started the week I joined. This was a terrifying call for both of us- for me because I had taken a big risk, and for him because I started the call with “Ok just don’t say anything until I’m done explaining, no matter how mad you get.”

Given the general idea of what we were building, I was sure of three things:

• The backend should be built in Flask

• The data should be persisted in Postgres

• The data access should be done with templated SQL, not an ORM

Three weeks later, I had built a solid base for the application, and was started on the integrations. But, some requirements shifted. Not too dramatically, and looking back not in a way that I shouldn’t have anticipated. But suddenly this just was not going to work, at all.

I looked back on a previous project at the innovation lab that I asked to be onboarded to because it was falling so far behind schedule it was about to be canned. The offshore contract shop engineers were in over their head on what should have been a simple build: nothing worked, and every new feature was another slog. I took one look at the codebase, which was a quagmire of 1600+ line Node.js files and a MongoDB datastore that was more difficult to navigate than the streets of Boston, and started screaming about a rebuild. It was a huge argument, and only one other engineer was onboard. Eventually my boss pulled me aside and said “I know that this would be way easier to build in Django. You know it too. They don’t know it and they won’t know it because they’ve never done it. Stop talking about it and just do it.” So I did it, and the proof of the pudding was in the eating.

So to that extent, I just took the weekend and rebuilt the API and data access layer. Started from scratch, rebuilt it in Django, and by the end of the two days I had proof that it not only could, but should, be done. The conversation with my CTO about why I was pivoting was MUCH easier because I had this evidence, and also was ahead of the curve with about 90% of the implementation completed.

Here’s your challenge:

• Pick a stack, any stack, that you’re comfortable with. Something that you know better than anything else. If you can’t pick, go with Python, Flask, Postgres, and React if you want a frontend.

• Build an application. It should be decently scoped so you can do this in about 4 hours. You can also use an app you build using the Time Trial mode above.

• When you’re done, start again with a different web framework, for example, Django. And maybe a different frontend like Vue.

• When you’re done with that, go with a whole different language. Do your backend in Go, or Rust, or Javascript. Switch out the database as well.

• When you’re done you should have 3-4 different applications that all do exactly the same things and look identical from the exposed interface, whether it’s the UI, API endpoints, command line, etc.

What you’ve learned is not only how to work in each of these stacks, but you’ll have a better intuition about what to pick for a project because you’ve experienced each one. You’ll also get some good experience in what is essentially software migrations, which are very common projects in the modern era of software development.

Build To The Sky

The last mode is one of my favorites because it’s FUN. And I put that in bold and all caps because I’m not afraid to admit that I’m a huge nerd. No complex story here- this is modeled after the typical lifecycle of a piece of software, with a little bit of RDD thrown in.

• Pick an application. It can be something you built in a previous mode, or you can pick a technology you use regularly such as Substack, Discord, Twitter, etc.

• Build the minimum viable product. Make it insanely tiny and borderline useless in how simple it is. For example, if you’re building twitter, make an API that let’s you create tweets, and returns all of them back.

• Add a technology that accomplishes another feature. Maybe start with authentication. You can pick an Auth provider based on the following decisions:

  • Which one do you see on job descriptions and want to add to your resume?

  • Which one do you know of, or have seen used, but don’t have much experience with?

  • Which one can you use w/o having to pay for it?

• Then add another technology that accomplishes another feature. Maybe now people can tweet with images, so you add S3. Maybe you then add a CDN. Maybe you then add a Kinesis queue to manage processing the image into a thumbnail size.

• Do it again. Maybe you add some infrastructure such as Kubernetes or Terraform or Docker.

• Do it again. Maybe you make it faster with caching in Redis or MongoDB or DynamoDB.

• DO. IT. AGAIN. Maybe you add a recommendation algorithm to help users find more people to follow, and an A/B framework to test how you implement these features, and a… ok you get the point.

• DO IT AGAIN AGAIN AGAIN AGAIN AGAIN

My bad- I got carried away there. But maybe that’s the point of this exercise. When you’re done (you’ll never be done!) you will have not only added a bunch of buzzwords to your resume, but you’ll have seen what it’s like to watch a codebase grow from a tiny little kernel of opportunity into a huge Frankenstein’s monster of technologies duct taped together to make something work. If you’re thinking “idk that kinda sounds like some script-kiddie shit” then yes, you are right, and there’s a reason that a 2010’s script kiddie just cut you off on the 101 in his McClaren.

Ok Now WHAT DO I BUILD?

Oh yea, about that. Sorry to tell you this but…

It doesn’t matter.

I really don’t care what you build and you shouldn’t either. Just pick a random technology you use and mock it. After all, the best chefs learned by drilling Julia Childs’ recipes, the best artists learned by painting the masters, and the best musicians are Creed and only Creed so I don’t really know why we keep making more music, just stop already.

Scott Stapp can take your career Higher *guitar noises*

Ok well, that’s enough of me for one week. If you’ve made it this far, here’s some ideas on what you can build:

• Chat Bot

  • A simple frontend that allows a user to send a message to the backend. The server should respond asynchronously with some sort of acknowledgement. When you close the browser and reopen it, the messages from the prior session should still be visible.

• Twitter Clone

  • Keep it simple- you can post tweets from a user, select which users you follow, and see your timeline from tweets those users have posted. If you want to skip Authentication, just show a list of all the users in the DB in a dropdown so you can pick which one is sending the tweet.

• TicTacToe

  • Two users are able to play TicTacToe, on different computers (local network is fine), and the server determines who won.

• DIY AI Agent

  • If you want experience using OpenAI or Anthropic’s API, build your own frontend that allows you to send and receive messages. Bonus points if you add a dropdown so you can choose which agent, and which model, you’re communicating with.

• Robo Trader

  • Build a server that can be seeded with some amount of fake money, and have it “buy” and “sell” stocks. Give it a dashboard where you can view the balance over time, as well as all buy/sell events. This will be a fun testbed for learning how to use different basic (or advanced) machine learning techniques to optimize your chances of cutting off some poor sap on the 101 in your McClaren one day.