You have to fit the job

Dear new developer,

A few years ago I was job hunting (during a hot job market and with almost two decades of experience) and had a lot of people turn me down or say I wasn’t a good fit. Sometimes it was for coding ability, sometimes it was for familiarity with various systems, sometimes it was because I wanted too much money. I have turned down or left jobs for a variety of reasons, including money, demands on my time, or even just a bad feeling.

What I want to drive home, dear new developer, is that a job needs to fit both sides. The employer and the employee should both feel like they are getting a good deal.

The honest truth is that this means that there are some jobs that you could perform well at that the employer doesn’t know, believe or trust that you can. That can be a blow when you are looking for work. I’ve been there, hungry for anything that will help pay the bills. But you have to have faith. And keep looking. There are lots of developer jobs out there, at big companies and small companies, product companies and consulting companies, software companies and companies that don’t know they are software companies yet. And often, especially as a new developer, you can get hired for your potential.

I’ve also been in jobs where I contorted myself, either a little or a lot, because I thought that was what was needed. I’m all for taking one for the team for a while and doing an unpleasant task or job. But if I have to do it for months and years then that is the wrong job for me.

You have to fit the job, and the job has to fit you.

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

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.

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