Coding is like a puzzle

Dear new developer,

I have recently been doing a lot more puzzles. It’s a low tech way to spend time with the family. As I was working on one recently, I snapped two large sections of a puzzle together. It was very satisfying. I mused on how working on a jigsaw puzzle is a lot like coding. You work on small pieces, checking back in periodically with the big picture. Slowly, slowly, you build up toward your goal, which is a working system or a finished puzzle.

Puzzles are like software development in other ways too. For one, it helps to take time away from both a puzzle and a software system periodically. Often when I take a break, I return with both renewed excitement and additional insight. The break can be a night’s sleep, a pause for lunch, even something as simple as a short walk.

Another way I can make progress in either case is to shift my focus. When I’m working on any problem, there are multiple tasks that need to be done. Some are hard, some are easy. Some require deep work, some require conversations with other team members, domain experts, or customers. Just like you can shift from from one section of a puzzle that has you stumped to another, shifting from one software task that you need to do to another is a good way to maintain forward progress. Nothing saps my motivation more than beating my head against a wall.

Finally, the satisfaction when you bring all the pieces of a software system together is similar to when I finish a puzzle. Watching someone use a completed system which I had a hand in building is a joy.

However, puzzles aren’t a precise analog to software systems. There are some substantial differences.

First off, most software systems are far larger than puzzles, often involving the efforts of tens or hundreds of people. Puzzles seem to max out at around four people or so, and even then there are delays where one person is waiting for the box or to get access to an area of the puzzle. And software systems are built to work on problems that affect people’s lives, as opposed to being an amusing hobby.

Also, with a puzzle there is a known end state; the picture on the box is what you’re aiming for, and you can constantly checkpoint against that; unless of course, you’re working on one of these. An essential difficulty of software is that the end state isn’t typically known with anything like that level of precision. In fact, in most systems I’ve built, the end state changes as the team builds and learns more about capabilities. Check that, I remember one time we had a prototype mobile app in Cordova and we were able to rebuild it using native libraries. Of course, that got outsourced, so maybe it’s better that the end state changes.

Another difference is that with puzzles I always start with the easy stuff. The corners and edges of a puzzle are usually the first major components that are done. With software, that’s a recipe for disaster. I always work on the hard parts as soon as possible, preferably first, because doing so decreases the risk of a failure. There are always more and less risky sections of any project and my advice is to tackle the areas of least certainty and highest risk as soon as possible. It’s scary, but if you wait, it’ll only get scarier.

Sincerely,

Dan

Software is about people, not code

Dear new developer,

When I was starting out, I thought that software development was all about code. After all, that was the main thing I was working on. Well, maybe not the main thing, as I needed to know what code to write, how to interface with other code, what was the problem being solved, how to deliver it, the correctness of the code, and how it could be maintained.

But, the writing the code felt like the most important part of the job. It was certainly the most tangible and fundamental. After all, if the code doesn’t work, all those other things won’t matter, right?

This led me to focus on how to write code. I wrote up a style guide for the company. Researched new technologies. Read and commented in online forums. Learned how to decompile java bytecode to reverse engineer proprietary software. Argued about code formatting. Joined a design patterns discussion group. Attended meetups and blogged.

I undertook all of these activities to be better at writing code.

However, I eventually learned that people were far more important for the success of a software project than code. This crystallized for me after I saw a few very interesting (to me!) codebases abandoned for lack of a market or other business flaws.

This was a surprise to me, insofar as I’d assumed the code was the most important part of software development. But really:

  • Software and code is created for people and their purposes. It doesn’t exist on its own, isolated from human needs.
  • People will use the tools or applications built with code (or, worse, they won’t). This means that they have to be bought in to what is being built and consulted about functionality.
  • Most people don’t know or care about the code. (If they did, they’d likely be a developer.) They’re just trying to get something done. The most beautiful, well tested, flexible, configurable, documented, future proofed codebase that does the wrong thing is useless.

At the end of the day, code is a general purpose tool, just like accounting or research and development. Code must solve real world problems of real people.

Sincerely,

Dan

What is the best surprise of being a new developer?

Dear new developer,

I was asked recently at a talk I gave about what was the best surprise of being a new developer. I was talking at Turing School, and had discussed some of the things that surprised me when I was starting out.

There are a lot of great things about being a developer. For all that is wrong with the software industry, when you are a developer:

  • flow happens
  • you are doing office work (typically)
  • there are smart people around you
  • you are paid well (compared to many many jobs–median pay for any job in the USA is 32k in 2018 and for software developers it is 105k)
  • you get to learn all the time

So all in all it’s a pretty great job.

But the best thing and what surprised me a bit as new developer (and makes me sad) is how much developers are listened to. Or, rather, how little folks in other professions are consulted and listened to (based on anecdotal evidence and conversations, sorry no hard data).

So, being a developer (in a healthy team and company) means that your opinion is heard.

Sincerely,

Dan

How to market yourself as a new software developer

Dear new developer,

This post from Corey Snipes, an experienced software developer, is well worth a read. From the post:

People skills help so much. It’s hard to overstate that. I am a competent software developer, but I am really good at working on a team and that has carried me to increasingly sophisticated and interesting work my whole career.

There may be some kinds of software jobs where communication is not important. Maybe something in academia? Maybe finance? I don’t know, but every software job I’ve ever been in has fallen into one of a few categories:

  • working on a team. Here communication is important as it helps keep the team aligned and moving toward the correct goal
  • working by myself. Here communication is important because I’m talking to customers about what they need.

So I agree with Corey that communication is crucial.

It’s important to be clear about your limits but also about your potential. New developers are hired for potential. Again, from Corey’s post:

Be honest about your capabilities. Some people will say “fake it till you make it” but that doesn’t work for me and I’m no good at it anyway. I’d rather work with someone who knows their limitations than someone who thinks they know everything, and that’s the sort of person that I try to be. Figure out how to acknowledge your inexperience without making it sound like a problem.

The post is full of other good tips for folks starting out. He talks about two different places where a new software developer can deliver a lot of value: a paid position in a large software team and a volunteer position building something for a small business. I’m not a huge fan of volunteering because I feel like people should be paid for value they provide, but I understand that when one doesn’t have a track record, one needs to build one any which way. Open source contributions are a great way to do that, but this activity is less focused and a longer play than finding a local business that needs a website and just putting one together.

Another tip that resonated was going to meetups and getting out into the community, but I’ve already written about that.

Sincerely,

Dan