You’ll always be learning

Dear new developer,

One thing I love about software development is that you’ll always be learning. This is because of two things.

First, there’s better and different hardware. It is possible that this pace will subside sometime, but looking at the variety of new computing hardware, sensors and components that have been created over the last 60 or so years gives me confidence that we’re at the beginning of computing becoming a utility, just like electricity. This is one of my favorite essays on the topic. This new hardware gives rise to new capabilities. Just like GPS in the phone gave rise to Lyft and Uber, I think that small connected sensors everywhere will give rise to new companies and software development opportunities.

The other reason why you’ll always be learning is that software itself is evolving. This is a very young profession. I believe at some point it’ll be as established and systematic as, say, civil engineering, but I think that’ll be decades if not longer in the future. That means that practices and tools are continuing to evolve. They both take advantage of new hardware, of practices learnt from other disciplines, and of lessons as systems are built. I already gave you an example of the first, but an example of practices lifted from other areas of knowledge is chaos/resilience engineering. An example of the last lesson is containerization and immutable infrastructure.

If you choose to be a developer, your career will be filled with learning. Enjoy.

Sincerely,

Dan

Meetings are work

Dear new developer,

I remember when I started out, I thought meetings were a waste of time.

All those people in a room (now a Zoom), discussing an issue. Folks would go back and forth, and at the end of the meeting you’d hopefully have a decision. But often the output was just more research or discussion. You might have to go back to the client, the team, or vendor and ask more questions. This would be followed, you guessed it, another meeting to relay the results.

I just wanted to code! I wanted to be told what to do, or if that wasn’t an option, take my best reasonable guess, and program.

Meetings sure seemed like a waste of time.

Now, many years and meetings later, I realize that meetings are really work. They help align teams, ensure you are building the correct things, and share knowledge. These are key parts of delivering software and making sure that all the programming isn’t for the lost cause.

Yes, you can do many things asychronously. I enjoy flexible work hours and chat tools and pull requests and email lists. But whenever I see an email or other async conversation look like it is going to go off the rails, I jump in and suggest a meeting. It may be a pain, but it will let you cut through days of unclear emails. For example, I remember meeting with a vendor in India at 8pm at night, because that was the time that was least inconvenient for the both of us. We were able to resolve questions we’d been exchanging emails about for days with thirty minutes of conversation.

Meetings define and push the work forward every bit as much as programming.

Sincerely,

Dan

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