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

The despair of not being good

Dear new developer,

I recently learned a new skill. And I wasn’t good at it. (The skill, if you must know, was writing with a certain tone for a corporate blog. But the lessons below apply for any skill.)

I don’t like being “not good”, aka bad, at something. Especially since it was adjacent to an activity I’ve been doing for years, which is blogging.

I would get feedback on how to improve this or that. I understood the feedback, it made sense, but the overall feeling I had was of failure. I felt shame because this was something I thought I knew. That honestly pissed me off. But after the shame passed, I acknowledged that the comments were correct, that I wasn’t producing what I should.

It’s important to acknowledge that it’s OK to fail (I’ve covered that before) and that it’s OK to be bummed about it. We’re all human and the emotions are part of it.

I had a couple of choices. I could keep trying and make improvements over time. Or I could decide that, hey, maybe this wasn’t the right task for me to do.

The question is, how do you decide? I think there are a couple of ways to think about this choice:

  • how core is this skill to your job?
  • how core is this skill to the company?
  • how long do you think it’ll take to get good?
  • do you enjoy it? do you want to be good at it?
  • is there another way to solve the problem other than you doing something you’re not good at?
  • is there someone at your company who can help teach this to you?

Note that it isn’t just your opinion on these that matter. You also want to make sure you get your boss’s opinion, on each of these questions. The discussion is important and will determine how and where to invest your time.

If you despair because you’re bad at something, don’t just beat your head against the wall. Step back and be strategic about your efforts.

Sincerely,

Dan

It is never too late to start learning how to code

This is a guest post from Jenna Quindica. Enjoy.

Dear New Developer,

I didn’t learn how to program until I was 18; in fact, I didn’t know about computer science the concept until I was 18. It is never too late to start learning how to code.

In the beginning I struggled the most with navigating acronyms, words, and phrases I’d never heard of. I vaguely knew what a server was, but I didn’t know what a command line was, let alone what you do with one. File extensions that weren’t Microsoft Word, Excel, or PowerPoint confused me. The closest I got to computer science as a kid was clearing my Chrome browser history. My Neopets password was five alpha characters, and I was devastated when my account got hacked.

I didn’t start to enjoy programming until I knew how my piece fit into the rest of the picture. Find a friend who can teach you the vocabulary so that you can better understand the ecosystem.

Warmly,
Jenna

Jenna Quindica is a software engineer at First Round, a seed-stage venture capital firm. She dropped out of her computer science major at Cornell University to work at four early-stage startups. She lives in the San Francisco Bay Area.

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.

  1. Know what you want.
  2. Communicate that.
  3. 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.