Benefits of blogging

Dear new developer,

I’ve written before about my belief in blogging as a way to sharpen your thoughts and give examples of your expertise. Here’s a post along the same lines. From the post:

People always try to find someone they can trust. You can go through a series of interviews and hope that they will figure out you are a great colleague, or you can write about your approaches and let a wider audience know that.
If you have a deep expertise in some technology, you can demonstrate it by writing deep and thoughtful blog posts.
If this technology is in demand, you will definitely get some opportunities coming your way!

And

Your views expressed publicly can be a good conversation starter.

This may come handy in any professional social context: interviews, meetups, conferences. It’s a different level on conversation when you get approached because someone likes your views.

The author then goes on to talk about specific, measurable ways that his blogging has helped his career.

The whole post, “Is blogging useful?”, is worth a read.

Sincerely,

Dan

Learn to look around corners

Dear new developer,

Sometimes you want to play out things two and three steps deep. Kinda like chess players, who think about many moves ahead, if you can consider the ramifications of your decisions, you’ll be well served.

I remember talking to someone about a software position at his company and he referred to the “original sin” of choosing a particular NoSQL database. This had ripple effects throughout the life of the company. Some were good, some were bad.

These kind of downstream effects are worth thinking about. The biggest ones are things like fundamental platform choices (Rails or Django, Java or golang, mysql or postgresql). But even smaller things can have ripple effects. I can’t count the times when I’ve said “I’ll just upgrade this one thing” and then the change just keeps cascading out.

Or if you are working on a feature definition, think through the ramifications. “We want to allow people to change their email address.” But if email address is the primary key of a table, or a primary means of connecting data across accounts, or some other invariant, what will the ripples in your system be.

And these are just the functional repercussions. There are also performance repercussions to changes, some of which are hard to test unless you are in production.

I’m not saying don’t accept changes. That way lies madness (and Fortran). Just be aware of how changes in complicated systems like web applications have a way of rippling out beyond their intended scope, and consider how to test, mitigate or handle such ripples.

Sincerely,

Dan

Schleps

Dear new developer,

I remember reading this article a few years ago and being struck by the wisdom contained therein. Code and development is crucial to building many businesses, but as developers we often get wrapped up in the code to the exclusion of other things.

I have definitely discounted the value of other aspects of a business (marketing, sales, accounting) in the past. That is a mistake, as there are many many things that need to happen to deliver value to a customer.

Doing a schlep is a great way to inexpensively deliver value to customers. It doesn’t scale, but it is far quicker to change a manual process than to change code.

From the essay:

No, you can’t start a startup by just writing code. I remember going through this realization myself. There was a point in 1995 when I was still trying to convince myself I could start a company by just writing code. But I soon learned from experience that schleps are not merely inevitable, but pretty much what business consists of. A company is defined by the schleps it will undertake. And schleps should be dealt with the same way you’d deal with a cold swimming pool: just jump in. Which is not to say you should seek out unpleasant work per se, but that you should never shrink from it if it’s on the path to something great.

The whole post, titled Schlep Blindness, is worth a read.

Sincerely,

Dan

Think about how things can go wrong

Dear new developer,

Think about the edge cases.

This is one of the primary ways you can add value. Think about what happens when things go wrong. It’s usually relatively straightforward to consider the happy path. Let’s take the example of a relatively simple ordering application. People can login, see their orders, and can change certain aspects of their orders (their address, perhaps) before a product is shipped.

Begging the question of why aren’t you using an open source solution like Magento or a off the shelf saas solution like Shopify, there are other things to be aware of.

What happens if the user wants to ship some orders to one address and some to another?
What does the user see when they login but have no orders?
What happens when they change their address?
What kind of validation is needed?
How do we know when a product is shipped? What do we do if a user wants to change their address but the product has shipped?

These are all edge cases around the happy path of login -> change address -> exit. But they are all going to affect the user experience, and so are worth thinking about.

I prefer to do it at the spec time, but any time to ask these questions is a good one. Otherwise, you’re either going to have:

the edge cases pop up and be handled poorly,
or developers making up the answers while coding

So, new developer, when you get a change to talk about a feature, think about the happy path, the expected path, to be sure. But also think about how things could go wrong.

Sincerely,

Dan

Things learned from a senior developer

Dear new developer,

This post by a Bloomberg developer catalogs everything they learned sitting next to a senior developer for a year. Lots of good stuff in there. Favorite excerpts:

How to handle an outage:

For when things go wrong, and they will, the golden rule is minimizing client impact.

My natural tendency when things went wrong were to fix the problems. Turns out, it’s not the most optimal solution.

Instead of fixing what went wrong, even if it’s a “one line change”, the first thing to do is rollback. Go back to the previous working state. This is the quickest way to get clients back on a working version.

Only then should I look at what went wrong and fix those bugs.

This is really good advice. When you are under pressure in a production outage, the tendency to try to figure out what is going on can be very powerful. However, figuring out the root cause of the issue is probably not as important as restoring functionality to your end users. Roll back. If you won’t be able to replicate the issue in your staging environment (due to load or some other reason) save off your logfiles and note the start and end times of the outage for further analysis (slack is good for that).

On code reviews:

Code reviews are amazing for learning. It’s an external feedback loop on how you’d write code vs how they write it. What’s the diff? Is one way better than the other? I asked myself this question with every code review I did: “Why did they do it this way?”. Whenever I couldn’t find a suitable answer, I’d go talk to them.

After the first month, I started catching mistakes in my teammates codes (just like they were doing for mine). This was insane. Peer reviews became a lot more fun for me – it was a game I looked forward to – a game to improve my code-sense.

My heuristic: Don’t approve code till I understand how it works.

Code review is definitely a skill worth practicing. You don’t want to nitpick and I’m a fan of automated linters/code style enforcers. That way you can have all the ‘where does the brace go’ arguments once, and then have the rules automatically enforced. Of course you can look for bad variable and function names, and that is valuable (and non automatable). But in my mind there are two aspects code review that are harder, but more important:

How does this fit into the overall system. Are there other components that should use this code or be used by this code? Is this structured correctly?
Do I understand this code and what it is trying to do. This means you need to understand the problem that the code is solving.

The whole thing is worth a read.

Sincerely,

Dan

The Art To And Power Of Saying No

Dear new developer,

There’s an art to saying no. And there’s power in doing so.

I worked on a project that was creating a Yahoo clone early in my career. The lead developer got sick. I said “yes, I can help.” I jumped in and helped out, a lot. I ended up working 96 hours in a single week. The site launched. I was thanked by my company with … a t-shirt and six-pack of beer.

I have learned since then how to say no.

The art is in saying no without being a jerk, and to making sure that everyone realizes that they are all on the same team. My best advice for that is to flip things around and say “yes, but.” “Yes, I’m happy to shift to working on task B, but should I finish task A first.” “Yes, I can help you with the release, but Jane is waiting on this feature.” This makes it clear that you are happy to help, but have other obligations as well.

After you describe the two options, ask for prioritization. Especially as a new developer, you simply don’t have the bigger picture. Maybe task B is blocking three other developers from making forward progress. Maybe that release is really important because of a bug fix that needs to go out before the launch of a new product. I have never once been dinged when I asked for prioritization. It shows that you care about working on important things, are aware that there is a bigger picture, and are flexible.

However, be aware that as soon as you juxtapose two tasks that both need to get done, you will be asked to estimate those tasks. Practice that, as it is a skill you’ll need as a software developer.

The power of saying now is in protecting your time. You only have one life to live (#yolo). When you have a salaried job, there’s very little downside to your company in trying to take more hours. Even if they are really nice people, you are the person responsible for establishing and protecting your boundaries.If you say yes all the time, you may end up working a lot of hours.

The other issue is that it feels good to work, especially as a new developer. “Look, I’m getting stuff done.” “I’m building cool stuff.” But the point of life is to live, not just to work. As I look back over my career, I’m proud of what I’ve built, but a lot of what I’ve built is gone. Don’t let a company suck you in and not learn to live a life.

Learn to say no.

Sincerely,

Dan

How to get the attention of a busy person

Dear new developer,

This post talks about how to ask for mentoring, but the principles apply to getting in touch with any busy person. Busy people are by definition busy, and get a large number of emails and requests every day. (Here’s a VC talking about the difference between ignoring and not replying, and how they look the same to a sender.)

The key is that you as the requester need to put in some effort. From the post:

In other words, when you asks for a busy person’s time for “mentorship” or “advice” or whatever, show (a) you are serious and have gone as far as you can by yourself (b) have taken concrete steps to address whatever your needs are and (optionally. but especially with code related efforts)(c) how helping you could benefit them/their project.

This effort on your part shows that you are serious. It qualifies you. Especially if you persist. (Now, you can’t persist to the point of annoying the person. There’s a line between persistence and bugging someone. I always preface any email I send to someone asking a favor with ‘hey, feel free to tell me to buzz off’, and I mean it.)

And

I hate to sound all zen master-ey but in my experience, it is doing the work that teaches you what you need to do next.

That doesn’t mean you can’t learn from reading (otherwise why have documentation or even this blog!) but that you need to actually try things outlined in docs. Even just typing the commands of a tutorial (instead of copying and pasting) will help you understand what you are doing.

The whole post is worth a read.

Sincerely,

Dan