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

The Code Will Never Judge You

This is a guest post from Lorna Mitchell. Enjoy.

Dear new developer,

Recently, I decided my seven-year-old niece was old enough for her first programmable device. She has done a little bit of Scratch with me, so I bought her a BBC micro:bit (a very simple programmable device, with a web editor and USB connection, some buttons and some LEDs) and showed her how to get started. Then I said to my sister (whose child this is) “the tears are all part of the software development process, so try not to worry when it happens!”. However many years down the path I am myself, coding is still a rollercoaster and there are some downs as well as some ups.

One thing that makes software development more difficult is wondering if you are really cut out for this. It’s so easy to feel like you are doing software “wrong” in some way. Spoiler: there really isn’t a right way, it’s part art as well as part science. Keep the user in mind and apply the technology the best way you know how; you’ll go far.

Some days it doesn’t feel like it’s going well and you may wonder if you will ever be really good at your chosen profession. On other days, or perhaps overlapping days, other people will think you’re not cut out for it either. Maybe you think your skill set isn’t a good fit (it is), or that you don’t really look like a software developer (you do). It is very difficult to help other humans who have already decided that they don’t quite believe in you. From extensive field testing, I have found that almost none of them ever change their mind.

In fact, this is much less important than it seems. If you don’t understand the pop culture that inspired the bot/server names, you didn’t play the same computer games or watch the same films (I’ve still never seen Star Wars), that doesn’t impact on what you can be. For minorities of all stripes, not sharing the supposedly shared culture can really make you doubt yourself. That’s a human reaction, don’t feel bad for feeling your feelings. If you want to be a person who does play those games and watch those films, then go for it.

But if you are just there to be the best software developer you can be, then let the other things go past you, and focus on the things you really do want to learn from, and share with, the crowd. I think most of what I know about text editors, information security, and leadership I learned from colleagues or conference encounters. It took me far too long to realise that software developers do look and sound like I do, and my own interests and hobbies are no less valid than anyone else’s (I also know more very technical humans with yarncraft hobbies now).

The code will never judge you. You show up, try things out, keep learning, keep iterating. That’s how software is made. It isn’t made of what other people thought you could do, it’s only made of what you did do, and for that you need to show up, and do.

— Lorna

Lorna is based in Yorkshire, UK; she is a Developer Advocate at Vonage as well as a published author and experienced conference speaker. Lorna is passionate about open source technologies and sharing knowledge, code and experiences with developers everywhere. In her spare time, Lorna blogs at https://lornajane.net.

When do you feel like you’re “senior”

Dear new developer,

I thought this was a great tweet. It’s worth clicking through and reading the responses. I wrote my own tweet in response, but thought I’d write about it a bit more here.

First, it’s worth acknowledging that the term “senior developer” means different things in different places and times. Certainly the knowledge expected of a senior developer in 2020 is different than in 2010. And likewise, a senior developer at a small consulting company will probably be ineffective at Google and vice versa. I’ve written more about the various types of senior developers here.

It is also worth pointing out that a senior developer isn’t the same as being a good coder. A senior developer has that skill plus many others. So, how do you know you are a good coder? In my mind, there are three attributes:

  • You know your tools
  • You can figure out what the right code to write is
  • You can make the right set of tradeoffs

Let’s examine each of these in turn.

First, it’s important to know your tools. These could be low level tools like the syntax of your language or your text editor. They could be higher level tools, like an open source framework or a custom library. They could be computer science focused tools like a parser.

But you need to know these tools and what are the right ones to apply to solve the problem at hand. Otherwise you’ll either be re-inventing something that has already been done or trying to apply the wrong tool to a problem (much like using a saw to hammer a nail; can be done, isn’t pretty).

Next, you need to figure out what the right code to write is. Even if it is no code. This means that you don’t expect to be handed a full set of requirements from some all knowing figure. It means you dig in and understand the domain. That you apply your knowledge and skills to the problem. And that you use the above tools to solve the problem within the constraints that you are operating.

For that is the final piece. Every bit of code has its own context in which it was written. The code that you write to load a CSV file one time can be undocumented and slow. The code that you write that will be executed multiple times by every application user should be polished, tested and fast. As a senior developer, I think you know that “good code” is context dependent.

You understand that context and make appropriate choices to get the job done.

Sincerely,

Dan