On debugging, v2

Dear new developer,

I wrote about debugging a few weeks back. I wanted to get more concrete. One time a friend called in about his client. The client was getting doubled orders on their ecommerce site. That is, someone would order five widgets on their site. The system would have some kind of hiccup and there would be two orders, resulting in ten widgets being shipped. It didn’t happen every time. It didn’t have any discerneable pattern. There were no obvious changes to the system that would cause this.

The customers weren’t happy about this. The client wasn’t happy about this. My friend wasn’t happy about this. He had looked around and couldn’t find the issue. He wanted me to take a look.

I had never worked with this ecommerce system before. There was no staging environment. I was debugging in the dark. I didn’t even have a way to submit fake orders that wouldn’t be charged. What I had was server access and SQL database access and a list of the customers that had been double charged.

So I started looking around at the log files (on the command line, with grep and vi and all the other great unix tools) and noticed that something weird had happened. The apache logs indicated that the server was restarted very often. The times when the server was restarted also lined up with the double charges.

I looked at the server cron file and found that someone had added a line that restarted the apache web server regularly. I asked if anyone knew why this was happening; no one did. They didn’t have their system changes under version control, so I was ginger about making changes. But finally I decided to disable the restarting of the server and see if the double orders continued.

They didn’t.

So this was definitely not a hugely complex system, but this is an example of debugging in a live system. Lessons for me:

Define the problem
Know the finish line
Start with what you know
Take small steps
Notice anything “weird”

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

Manage your career

Dear new developer,

You have to manage your career. If you don’t, no one else will.

This means three things.

Know what you want.
Communicate that.
Make moves toward it.

Let’s talk about each of these in turn.

“Know what you want” is the hardest part. Because we are lucky to live in a world with lots and lots of options and opportunities. You can focus on one of a 100 different kinds of software development. And that is to say nothing about other related opportunities (product management, teaching, engineering management, etc) where your developer skillset will help set you apart.

My advice here is that you should pick one and follow it while it is interesting. If you have fundamental skills (problem solving, learning, listening, typing), you’ll be able to transition between areas. It may not be an easy transition and you may pay a price in terms of compensation or status or ego. You may have to spend precious time outside of work getting up to speed. But no decision is permanent. So pick what is interesting. Commit to it for a period of time (six months, a year). Realize that you can change (though, as mentioned above, that may have a cost), so commit.

“Communicate that” because if you don’t talk about what you want, you will have a hard time getting it. This is because people generally want to help, but need to know how to help. So, communicate your desires to your manager, to your communities, to your friends, to your co-workers. You don’t need to mention it every day, and you should tune your communication to your audience.

For example, if you are a web developer and want to be database focused, then volunteer to work on database projects. Mention it to your manager at your 1:1s. If there are people that are doing database work at your company, ask if you can meet them regularly.

This doesn’t mean you can avoid the web development work for which you are paid. What it means is that you can tune your work environment toward your interests. Not immediately and not at all companies, but often.

“Make moves toward it” means you aren’t just talking about your desired direction, but you are actually taking steps toward acquiring skills and doing that work. To expand ont the web developer -> databases example, take action. Present on databases at a meetup. Do a brown bag on databases at your company. Read a book about databases. See what you can apply to your current work.

However, sometimes you can’t make a move internally. Maybe the opportunity just isn’t there. Maybe the company needs you in your current spot. You may have to switch jobs. That’s OK.

Don’t burn any bridges, but when it is time to move on, move on. Find a new job with your new skills and knowledge, hopefully from the community you’ve found. Give notice and head off to a new adventure. (Don’t forget to connect to colleagues on LinkedIn.)

What’s the alternative? Floating through your career, buffeted from opportunity to opportunity, or worse, from job you’re afraid to lose to another job you’re afraid to lose.

That doesn’t sound like much fun.

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.

Develop empathy

Dear new developer,

Right now you’re probably a bit frustrated and confused. You’re learning a lot of things and you don’t really understand everything. Sometimes things click and it all makes sense, other times you’re confused and staring at what feels like a brick wall. Perhaps you just want to make things work and they won’t.

Good.

I say that not because I’m a sadist or dislike you. I say that because I hope you’ll remember the frustration you are experiencing right now. I think that will make you a better developer.

Why?

Because that is the state of 99% of your users. Whether they are a business employee or a person trying to use your app for personal reasons. They are just trying to finish a task and get on with their life. The software you are writing is the tool they are using to do that.

They don’t care about elegance of code.
They don’t care how much you love to develop.
They don’t care if you are learning and growing.

They just want to finish their job, complete their task, do their thing.

And, honestly, the tools we provide are frustrating. They’re buggy. They’re slow. The fact that they are amazing compared to what we could create a few years ago and that they are better than the alternative is beside the point.

I don’t write this to cause despair, new developer. Progress is being made. But it’s made one person at a time. Each person has to act with empathy toward their frustrated users. Understand them. Care about them.

And if you can remember the frustration you are currently encountering, perhaps you’ll have just a bit more empathy toward your end user, who is just trying to use your work product to get something done.

Sincerely,

Dan

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

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