Why software engineers are grumpy

Dear new developer,

I thought that this post, “The care and feeding of software engineers (or, why engineers are grumpy)”, from 2012 was still relevant today. It’s a long one, so I won’t excerpt all the interesting parts, but this really resonated with me:

Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.

The author explores the metaphor of the house, and how you really should fully define such a structure before you start building it. And yet, sometimes software is “just started” and defined and re-defined as needed changes are discovered

The author doesn’t let software engineers off the hook either:

Software engineers are put into a difficult position every day, but we are not victims even though those of us who are more melodramatic tend to act that way. Part of our grumpiness actually comes from within, with something that for some reason is deeply ingrained in the majority of software engineers. We have a tragic flaw and that flaw is that we overestimate our knowledge and abilities..

In addition to all the complaints engineers have, it also has a few suggestions about ways to help (including appreciate the engineer’s effort and cross functional training). Well worth a read as someone who either works with software engineers or as someone who is one.

Sincerely,

Dan

Confessions of a conference speaker

Dear new developer,

When I was newer to development, I thought that conference speakers were experts in their area, harbored no doubts, and that they knew exactly what they were doing. Speaking about technology seemed scary (until it wasn’t).

I enjoyed this post, “Confessions of a Conference Speaker”, pulling back the veil on the experience of a prolific tech conference speaker–20 talks in 2019. (She also has a post about being a conference attendee.)

I particularly enjoyed this section, titled “The Audience is Rooting for You”:

People come to conferences and attend your talk with the hope of getting value for their time. But that’s what is important to remember. They WANT to have chosen a good talk. They WANT you to succeed!

Being a speaker can be nervewracking for any number of reasons. There is so much prep that goes into it. Not every talk will go perfectly. But it helps to remember that the audience is rooting for you. This is especially true with those live coding mistakes. They’ll enjoy helping out 🙂

And the tips about a tech check and adding your author info on every slide were spot on based on my limited experience.

I can’t recommend public speaking enough for a a way to level up your skills. It can be terrifying, but you’ll learn:

  • how to dig into a topic
  • how to present something in a coherent fashion
  • the confidence of knowing that you (likely) know more than anyone else in the room on this topic
  • the value of connecting to your peers

If you are considering doing a talk, I’d suggest starting at a meetup or a lightning talk at a conference. Read the whole post to get Laurie’s inside view.

Sincerely,

Dan

Three principles for guiding your development career

Dear new developer,

I thought this article nicely laid out three principles to guide a developer’s career.

They were:

  • follow your taste
  • find community
  • take risks

Each of these really resonated for me. The first because the wide world of software can lead to analysis paralysis, so you should really have some way of deciding what you want to work on. When you are starting out you don’t have too many ways of doing so. Taste is better than random choice.

I’ve already written about the benefits of finding community (online or offline) and how it can help you grow.

Risk is an area I haven’t covered much on this blog, but in my own career I have overvalued stability. If I had it all to do over again, I’d take more risks, because I fall prey to overestimating the impact of failure on my life. (Of course, that’s easy for me to say looking back.) An example of that is that I waited until I was in my 30s to really commit to a startup; I had the skills to do so earlier, when it would have been easier financially, but I was too afraid to give up the stability and money of the consulting I was doing.

Here’s an excerpt from the article about following your tastes:

The default path is to follow what’s popular or prestigious. That can lead to a bunch of problems: What’s prestigious is already highly competitive. When you compete with smart people in a game that has established rules, just keeping up will take most of your time. That leaves little time to explore what interests you. When you don’t explore what interests you, you won’t understand things as deeply, and that leaves you with an undifferentiated skillset.

The whole thing is worth reading.

Sincerely,

Dan

On mid-career challenges

Dear new developer,

I really liked this post on mid-career challenges. I know you’re new, but you’ll be mid-career before you know it!

I’m in a position right now where I have to figure out what comes next for me and how to navigate the challenges of getting there. I made it to senior engineer, I wrote a book, I spoke at a bunch of conferences, switched from ops to dev back to ops again — so now what? For some people, mid-career looks like figuring out what your next set of career goals might be, what you might want your next 10 years of work to look like. For others, it might mean changing careers — you might be in a position where you’re quite senior in terms of core skills such as communication, team dynamics, and project planning, but you came into tech from another field so your coding skills still have leveling up to do.

As you get your legs under you as a developer, it’s worth peering into the future so you can set yourself up for success. Setting goals is part of that. So is learning from other’s experiences.

As usual, the whole post is worth a read.

Sincerely,

Dan

Contextual advice for new developers

Dear new developer,

A few months ago I asked Marie Chatfield, a front end developer and advice columnist, what her one best piece of advice for new developers was.

She wrote a great response. From the post:

For the self-taught programmer: I am amazed at your dedication and perseverance and ability to learn from different resources. Remember that other people have valuable things to teach you, too, and seek out trusted mentors or role models when you can. You will never stop learning in this industry, and you have shown already that you are ready and willing to put in the work. That’s going to take you far.

For the one who doesn’t see themself represented anywhere: I am so glad that you are here. I hope you can stay here for a long time. I hope you find communities that make you feel welcome and safe and included. You get to make the right choices for you and your health and safety, even if it makes others uncomfortable or disappointed. You don’t owe increasing the representation of a space with your presence to anyone. You belong here, and you should get to focus on doing the kind of work you want.

What I like most about this is that she gave contextual advice. New developers share many characteristics but are by no means a homogeneous group. The bootcamp grad who was a marketing guy previously is different than the computer science graduate who is starting her first job after college. They both differ from the kid who has been coding since they were twelve. I write these letters from a certain perspective, but know that everyone will read them from their own place.

I really also appreciated her advice to everyone:

 

  • It’s okay to fail. Everyone makes mistakes.
  • It’s okay to look things up. You don’t have to remember everything to be a good developer.
  • Everyone is nervous about interviews. They’re kind of awful. But you get through them.

 

I asked Marie for one piece of advice, but she gave more than ten. I enjoyed reading her advice to new developers and I hope you will too.

Sincerely,

Dan

PS She also has written some other great posts.

Leveling up tips from Chelsea Troy

Dear new developer,

I found this video from Chelsea Troy about how to level up as a developer interesting (I love watching YouTube videos on 1.5x speed to save time):

A few tidbits I found interesting:

  • the distinction between leveling up passively (which we all do as we learn in our daily work life) and leveling up actively (with a goal)
  • the importance of routine in this deliberate leveling up process
  • the idea of commit tracing as a way to learn a system (yes, version control is important)

You can also read the transcript.

This section about reaching out to experts also resonated. If you take the time to craft a good question, you can get the attention and help of even busy people.

Third, if I am struggling to find the answers to my questions in literature, I find myself asking, who can help me? I think it’s easy, especially in tech, to feel like you’re alone and you need to be able to solve problems yourself. But I have found that not to be true. Sometimes it’s a matter of reaching out to a coworker or colleague to get another set of eyes on whatever I’m working on. If that doesn’t work, then I’ll ask an expert. And I have been repeatedly surprised by the generosity of experts. The first time I ever needed to implement Spring Batch in something, we had a complicated use case and I somehow just couldn’t get it to go. So I reached out to the team, and one of the Spring core contributors pair programmed with me to get the thing working. Another time, I was working with XGBoost, which is a machine learning library that relies on a particular, custom-crafted data structure called a DMatrix. But I couldn’t find anything online about how the data structure was built, so I reached out to a developer advocate on LinkedIn, and she gave me an insightful answer.

I’m not saying her system will work for you wholesale. Whenever you’re learning what worked for someone else, you want to evaluate the methodology from your perspective. But she definitely has great ideas (she blogs on leveling up a fair bit) and I’d suggest you listen and try out the ones that excite or interest you.

Sincerely,

Dan

Things good engineers do

Dear new developer,

I found this post covered some things that good software engineers do. It doesn’t focus on the technical aspects, but on other aspects of software development. Things they do:

  • Ask for help
  • Work on one thing at a time
  • Prioritise unblocking

My favorite quote:

In software development we rarely have the luxury of a todo list with a single item on it. Despite this, we are not able to work on two things simultaneously. Every time you work on one thing and change to another you pay the cost of mentally (and sometimes in development environment) context switching. As a result the most efficient way to work is generally to take one task to completion before starting another task.

These are all key things for engineers to do. The first makes sure you aren’t beating your head against the wall unnecessarily. The second makes sure you can focus on one thing and avoid context switching. For many kinds of development work, this is the most efficient way to accomplish a task. The third acknowledges that you should optimize for team productivity over individual productivity.

Three great pieces of advice. Worth reading the whole post, “Some Things Good Engineers Do”.

Sincerely,

Dan