Plan first, then code

Dear new developer,

I thought this article was worth sharing, as it is a relatively inexperienced developer talking to newer devs. But as I read it, one piece of advice stuck out and is worth emphasizing.

Plan first, then code

Roberto Hernandez

This is fundamental. Unlike, say carpentry, where planning is critical because you waste material if you don’t, coding sometimes feels like you can “just start.” After all, if you make a mistake, you can delete the code and start over (as long as you’re operating on your own development environment, not production). Seeing what you’re building is satisfying, both to you as a builder and anyone else you share your work with.

However, “just starting” is a recipe for waste, if what you start is writing code.

The first thing you should do before writing a single line of code is understand the problem. Depending on the size and scale of the problem, confirming this understanding could be as simple as repeating the request back to the person who made it: “so what you are saying is you want me to change the button text to blue” and thinking through the ramifications: “that will work on form A and B, but what about form C?”.

Or it could be as complicated as writing up a specifications document with the proposed changes and architecture, getting feedback on it, running it by the appropriate people or committees, and getting sign-off from stakeholders, including executives and customers.

Then, after you confirm you understand the problem and proposed solution, plan on how you are going to execute against it. For a small problem, this could involve starting immediately by writing or thinking of a list of tasks to do, though often you’ll want to add it to a todo list or calendar to ensure this task isn’t lost among the sea of other tasks you have. For a larger problem, there may be cross team coordination required, so: meetings and documents.

After you understand the problem and have a plan for how to accomplish this goal, you can begin writing code.

Avoid jumping in and writing code because the time to feedback is long. Compared to what? Compared to text, images or meetings. These are so much easier to iterate. If you write some code to solve the wrong problem or address it in the wrong manner, you’ve used more time than you would have if you’d talked through the problem.

It is also harder to communicate concepts with code, especially with non technical colleagues. Even with fellow engineers, a diagram or conversation is an easier way to explain ideas than written code. I’ve often whiteboarded a solution in a fraction of the time it would have taken to prototype it. Code is more precise and you can’t handwave a problem away, but there’s lots of chaff around the germ of the idea in many code bases.

There are times when writing code is the right way to start, though. This is called prototyping and if there’s no way to gain an understanding of the problem by reading, learning, discussing or otherwise approaching it, write some code to explore it. However, be prepared to throw this code away, as it will be the equivalent of a hastily scratched note on a napkin.

I do want to emphasize that this understanding and planning process doesn’t always have to be heavyweight and formal. In fact, for smaller tasks, you may internalize this process and not even realize you are doing it.

Next time you are working on a small task, take a moment and think about how you break it up into even smaller bits of work: “ok, I need to add this form. Therefore I need a model and a view too, and what are the methods I should add to validate the input?”

You don’t need to produce documentation and artifacts for every decision, but you would do well to at least in your own head think through the tasks and the ramifications of those tasks. This will help you look around corners and see issues that may arise because of your solution. If you do, you can modify the solution, again, before any code is written.

Sincerely,

Dan

If you’re trapped in your job, what should you do?

Dear new developer,

Perhaps you took the first job offered to you. Perhaps you joined a friend’s company, then realized it wasn’t quite what you were promised. Perhaps you joined a company as the only developer and didn’t realize you should avoid working alone.

You might feel trapped by the money, trapped because you believe you promised to stay for a year or two, or trapped by the position, without the ability to grow.

The most important thing to do is to prepare to leave. How can you do so? Here’s a three part plan.

Know what you want

First, write down what you want. You know more about what you don’t desire, but you need to have a clear path toward what you want. I’ll open up a google doc and write down all the things I’m disatisified with about the current situation I’m in. That may be people, it may be responsibilities, it may be salary, it may be situation, it may be the manager. This venting helps me get clarity.

Then, take some time thinking about what you’d change to be happier. This may require some research. You can do a lot of research by googling and reading, but you may also want to reach out to some members of your community to ask about their jobs. Hey, I said this was a three part plan, I didn’t say you wouldn’t have to do some work.

Think about your runway

Next, consider your financial situation. Do you have money saved up? Can you cut costs? Figure out your financial runway. If at all possible, save up three to six months of expenses, as that will make any transition time much much easier. The alternative may be borrowing from friends and family if possible, or the credit card companies if not.

I find that even just the exercise of looking at my expenses and income cause me to be more aware of my spending. You don’t have to wallow in it (though plenty of people swear by living on a budget); rather the goal is to set yourself up for success should leaving a job turn into a longer period of unemployment than you planned for.

Reach out and interview

Third, interview. Find companies who you are interested in based on the previous thought and research, and apply. Look on the company website, but don’t apply through it. The best way to apply is to hand your resume to someone already at that company. I find applicant tracking systems to be mainly good at weeding me (and others) out. Use LinkedIn to find people you know at the company. This also lets you ask them about the company culture and the job. Lots of companies, unfortunately, have job listing pages that may not reflect current needs.

If you don’t know anyone at the company, see if you can start. This includes following people on Twitter, watching speakers from the company, and connecting on LinkedIn. Please please, if you connect to someone on LinkedIn, write a quick note: “I was just watching your presentation on Kotlin and wanted to connect with more people in the community.”

Don’t be transactional about any of these interactions; you’re trying to learn more about the position and company, but you also want to provide value to the other person. How can you do so? I dunno, every situation is different, so ask.

I also use a spreadsheet to track all my applications, including contact info, links to the the job, and notes. I always have a ‘follow up date’ column where I can put in when I should reach back out again. It is hard when you are in the throes of the job search, but remember that usually finding and hiring candidates is just one part of the hiring manager’s job, and so you might slip between the cracks. Take control, send regular follow up emails, and you can avoid that fate.

If you do get an interview at a company you like, this should give you some great information. How prepared did you feel? How competent? Did you crush it or did you flub the interview? By the way, flubbing an interview is never fun, but when you already have a job is about the best time to do so.

What was the reaction of the interviewer and the company? You may not get as much information as you want (I never do) but you’ll get some feedback. I like to update that spreadsheet with whatever I learned: was there a question I didn’t answer as well as I could have? Was there a technology I need to brush up on? Do I never want to interact with that company again? All good data.

Consider your situation

Now that you’ve have prepared with your wants, your financial situation and gotten feedback from the hiring market, you can reconsider your situation. Does it seem better now? Or are you still feeling trapped. Sometimes popping your head up and looking around at other opportunities can actually make you happier where you are. Other times it reinforces your desire to move on.

If the former, go to your manager with a concrete set of changes you’d like. The amount of work to put into this depends on the scope of the changes. If you’d like more money, justify it with the value you are providing and how your salary compares to other like positions. If you want to spend more time on a different project or technology, make sure you understand how that would benefit the company, not just you.

Be flexible. If you want mentoring but there’s not money to hire a senior developer above you, ask if you can attend conferences or hire a senior developer on an hourly basis to bounce ideas off of. I had an acquaintance who regularly hired people on Upwork to consult with when he ran into thorny technical issues.

The point is to inform your boss, in a polite way, of any changes which would make you happier. Know that there might be no time or budget for some of them, but I guarantee that you’ll have a higher chance of making something happen if you present reasoning why both you and the company will benefit. Bosses don’t read minds.

If it is time to move on, keep interviewing and when you get an offer, leave professionally. Give two weeks notice (or whatever is typical in your country or spelled out in your employment agreement). Connect to co-workers on LinkedIn. And head off to your next adventure.

Sincerely,

Dan

How to make a move to a related occupation

Dear new developer,

I’ve written before about how being a developer sets you up for a lot of adjacent professions. Jobs like:

  • Engineering manager
  • Technical trainer
  • Startup CTO
  • Product manager
  • Developer advocate
  • Sales engineer

I have either direct personal experience or have watched a colleague or friend transition to those types of jobs. I’m sure there are many that I’m missing.

I had someone ask me about developer advocacy and how she could transition into it. I gave some off the cuff advice that I’d like to formalize in this post.

Moving to an entirely different career (“I want to be a rock climbing guide!”) is a bit different, but if you are transitioning to an adjacent profession, I think there are four parts.

Google

First off, find out more about the position: the responsibilities day to day, the types of problems you’ll face, what kinds of companies hire for the position, what kind of career growth is possible, the salary ranges, the challenges.

All this information will help you make an informed decision about whether a move is what you want to do. I’d spend a lot of time researching using Google because you can do that at your leisure.

If you decide from this research that you are interested in taking the next step, then you’ll want to talk to some people already doing the job.

Interview

Reach out to people who are or have done the job, whether internal to your current employer or on LinkedIn, and ask for their time. The research you’ve done previously should leave you with some questions. For example, for a developer relations position, you might ask the following questions:

  • How do I find companies looking to hire devrel folks?
  • How much experience do I really need?
  • What is the split of coding vs speaking vs writing?
  • Person X said Y about devrel, is that true in your experience?

If you do that, make sure you have a crystal clear agenda if you don’t know them personally, and that you communicate your focus. These folks are probably busy. Don’t start off the message saying you’d like to “pick their brain” for 30 minutes at coffee. Instead say:

I’ve been researching a career transition to developer relations and I notice you’ve been doing this for a few years. I’m especially interested in your experience at <startup> and would love 30 minutes of your time to ask some questions. If you’d prefer email, happy to do that as well.

If you are still interested in this change, the next step is to try it.

Give it a try

You should now have a good grasp of what kind of day to day work is needed for this adjacent profession. Now you want to try it in a low stakes way.

  • Want to be a trainer? Research and give a talk about a new technology in the area you want to train in.
  • If you are interested in product management, see if there are user interviews that need to be done for your current work. Can you sit in on one, or run it
  • Devrel interesting? Write some blog posts about a technology you’d like to promote.

From your previous research, you should be able to find an easy way to practice some of these skills. You could find an open source project looking for help, ask around internally, or start/continue a side project.

Doing this has two benefits:

  • You can learn even more about the profession.
  • When you want to make a transition, you can point to this work as an example that you have the skills to do so.

How long should you do this? Ah, another example of the secretary problem. I don’t know. But you should try it a few times, enough to give you a feel.

Finally, if you are still interested, take the plunge.

The plunge

You can transition internally or by getting a new job. If you do the former, the stakes are lower and you’ll come in with your existing reputation, which will presumably help you. However, it may be tough to do if the company doesn’t really have a need for the position. For example, I was interested in developer relations, but worked for a consulting company which didn’t have a developer facing product. It would have been difficult for that company to justify a developer relations position.

If you can, though, the internal transfer is a great way to go. While every internal political situation varies, if you think one is possible, I’d talk to the manager of the team to which you want to transition and to your own manager and see what they think. Is it possible? What is a good timeline? Should the transition be blended (two days in one position, three in the other) or have a firm cutoff? What would success look like?

In a smaller company, you may have more flexibility if you see a gap. One colleague stepped into product management successfully because she saw the company needed it and no one was doing it full time.

If you don’t see an internal option, interview with other companies. Be prepared with an explanation of why you want to make the transition and how they’ll benefit from hiring you. Your research and experimentation should provide you with plenty of anecdotes to share.

Finally, one nice aspect of software development is that if you take a year or three off in an adjacent field, you can come back. The change need not be permanent. You may need to brush up on some particular technologies, but in general I’ve found you can transition back fairly easily. And you’ll be a more valuable software developer if you know about product management, how to have a one to one, or marketing automation.