Patterns for managing up

Dear new developer,

Design patterns are common ways to implement solutions that can be repurposed across different systems and domains. This post proposes patterns for handling organizational situations.

Some really good excerpts:

No matter how amazing you are at your job, you will sometimes get feedback about things you could be doing better. It can be difficult to hear, especially if you are someone who works really hard all the time. When it comes to negative feedback, it is important to reframe the conversation. Feedback isn’t a bad thing. It is a gift, and you should always adopt a growth mindset and see it as a chance to improve.

I have received negative feedback about how I managed (I was managing how I would want to be managed, not how the employee wanted to be managed). It was really good to hear because it let me improve, but I definitely had to hold down a “wait a minute, you don’t understand” thought. If I hadn’t, I would have both lost that opportunity to learn, and possibly many more. If you react negatively to feedback often enough, people will decide that it isn’t worth giving to you.

And this is a good one too, about how to handle a problem you created:

When problems occur, there is a natural instinct to hide or deny that the problem is a problem, or that it is even happening at all. We want to minimize the problems that are our responsibility because, after all, a big part of our job is to make sure problems don’t happen. When you are proactive about sharing and fixing a problem, however, it is actually an opportunity to show you are an asset to the bosses.

Going to a boss and saying “I screwed up” is terrifying, especially the first time you do it. But going to the boss and saying “I screwed up and this is how I am going to both fix it now and make sure it doesn’t happen in the future” is terrifying but empowering too. The other alternative is to just hope that you are never found out, which is a miserable way to work (who wants to hide things? what happens if the problem gets bigger?). If you screw up, take a deep breath, come up with a plan, and solve the issue.

The whole article is worth a read.

Sincerely,

Dan

The right way to ask a question to get an answer

Dear new developer,

I already covered the right way to ask questions, but this post was so good that I wanted to share it. (I found it on hackernews.) Mike Ash gives advice on how to get answers from the internet.

Tips like “explain everything up front”, “post your code” and “follow up after you get an answer” will make it more likely that when you post a question on a forum, you’ll get some kind of help. The whole thing is worth reading, but here’s an excerpt that really resonated for me:

Many conversations I see indicate a subtle, buried belief that the list or chat is some kind of answer machine, and the key to obtaining a good response is to hunt around until the precise required format for the question is found.

It’s not a game, you’re talking to real live people. Treat them just as you would treat people you’re talking to face-to-face, and you’ll get much better results.

I have been one of those newbies under pressure to get something done. I’ve seen comments on github that lead to statements like this. It’s easy to forget that the folks helping you are

a) people

b) not getting paid by you

No matter how obvious the bug seems, or how much it is impacting you, you have to treat people helping you kindly. (You should do that even if you are paying people, by the way. If your boss doesn’t respect you, find a new boss.) Anyone who has run a volunteer organization knows that respecting the volunteers is the first step to getting anything done. Every time you ask a question on an internet forum or mailing list, you are essentially tasking a set of volunteers. Treat them right.

Sincerely,

Dan

Use stackoverflow, and use it well

Dear new developer,

Stackoverflow (SO) is great for three different kinds of developers (and someone can be all three over time):

  • those who are looking for answers, usually via Google (searchers)
  • those who are looking to showcase knowledge, usually by answering questions (answerers), and
  • those who have a specific question to ask (askers)

Every developer can be a searcher (all you need is Google). But you can look for answers poorly or well. Do it well by reading all the answers, understanding the question that shows up in the search results, and voting up both questions and answers. The voting in particular is a low effort way to add value to the entire developer ecosystem (because you are providing value to other searches). I know it is easier to take the first answer and move on with whatever task you are trying to get done, but try to take a bit more time and help others.

But you should strive to be an answerer or an asker. See if you can answer questions or add comments to clarify them or point to other answers. If you have a question that isn’t answered on SO, take the time to build out a solid question. If you end up finding the answer to your question, self answer it to help other folks out.

It is true that SO is not the most welcoming community, but it’s the preeminent question and answer site and so worth having a presence on. Don’t forget, the smallest amount of help you provide to SO may resound for years. I only have ~3k reputation but have reached almost 950k people. And beyond helping others, it’s a great way to demonstrate competence without venturing too far out of your normal workflow.

Sincerely,

Dan Moore

Don’t be afraid to ask questions

This is a guest blog post from Noel Worden. Enjoy.

Dear new developer,

Don’t be afraid to ask questions. It can be stressful and humbling to reach out and ask a question, but it can be the best way to stop spinning your wheels and make progress. It’s stressful because as a new developer you are trying to prove yourself to your peers and superiors. It’s humbling because you are admitting to someone that you don’t know something. Giving consideration to when and how you ask a question can make for a much smoother interaction.

So, how long should you grind away at a problem before you concede and reach out for assistance?  That can be a tough call, and can differ quite a bit based on your situation. Some aspects to consider are:

  • Is this meant to be a learning experience?
    • If so, you’ll want to spend more time looking for the answer before reaching out to anyone
  • How long do you have to complete the task?
    • The more time you have before the task is due, the more time you should spend looking for the answer yourself
  • How busy is the rest of your team and/or your mentor?
    • If no one has the time to help you unfortunately don’t have many options other than to stick it out and try to find the solution yourself until you see an opportunity to ask for help
  • Is the sticking point something relatively ‘small’ and holding you up from the bigger task?
    • Is it something like a bug in the project setup, or a hangup of a similar nature, that doesn’t have anything directly to do with the task? These types of hangups can be difficult to Google, or solve by experimentation, and are scenarios where asking for help earlier than later is probably a good idea.
  • Have you worked through other aspects of the task?
    • Sometimes skipping over the sticking point and working on other pieces can lead to an ‘aha moment’.
    • It can also help to gather multiple questions and therefore get multiple answers from one help session.

Once you’ve decided to reach out for help, the phrasing of the question can be important. When I ask a question I often try to go over what I’ve already tried, what I’ve Googled, and then what exactly is stumping me. This shows that I’ve made a solid effort to solve it myself, gives the other person as much context as possible, and helps avoid the person giving you assistance to not repeat the same unsuccessful troubleshooting attempts.

Most importantly, above all else, don’t be afraid to ask questions. Everyone was a new developer at one point in their career, and asking questions is a legitimate way to learn.

Sincerely,

Noel

Noel Worden started his career as a photographer, shifted gears to become a cabinetmaker, then graduated from the coding bootcamp Bloc. He is currently working as a software engineer for MojoTech in Boulder, Colorado.

Laziness, impatience, hubris

Dear new developer,

Larry Wall has created foundational software (perl, patch). He coined the three virtues of a programmer:

  1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.
  2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.
  3. Hubris: The quality that makes you write (and maintain) programs that other people won’t want to say bad things about.

These may seem crazy. Who wants to be seen as lazy, impatient or full of hubris?

But if you think deeply about it, Larry is saying that laziness makes you work in the short term to save effort in the long term. That impatience makes you write better code because computer time is less valuable than your time. And that hubris makes you want to develop software that you can stand proudly behind.

Makes a bit more sense, no?

Sincerely,

Dan

Ask smart questions

Dear new developer,

Asking questions well is one of the best ways to learn quickly. You can ask questions of the code, of other people or of search engines like Google. Here are excerpts of my two favorite posts about asking questions.

First, How To Ask Questions The Smart Way:

If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.

Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don’t realize that the path is wrong. It can take substantial effort to get past this.

This is a very long doc oriented towards helping people ask questions about technical issues in a way that will get them answered by busy developers. But there’s a lot of useful, if blunt, information, including how to look through Stack Overflow, how to ask on a mailing list, what to include and what to exclude, and what to do if you don’t get an answer.

Second, Ask the Duck:

One of Bob’s superintendants was in his office. He was grinning like a bastard around his toothpick. “Andy,” Bob said, “I don’t want you to pray to the duck. I want you to ASK THE DUCK YOUR QUESTION.”

I licked my lips. “Out loud?” I said.

“Out loud,” Bob said firmly.

Preparing to ask a duck, or really just writing up your question in enough detail so you’d feel comfortable posting it on a mailing list or Stack Overflow, often leads to you answering your own question. Sometimes the answer doesn’t come, but additional veins of inquiry pop up (“Ah, so I didn’t investigate upgrading that library, I should try that”), which sometimes lead to the answer. Or to a more intelligent question.

There’s a tradeoff of course. Doing the research to ask a good question is time consuming and can be frustrating. I always recommend asking people you are working with how much time to spend making this kind of effort. If the project is on a short timeline, it may make sense to ask a less prepared question more quickly, especially if it is to an internal team.

So, in a meta way, be prepared to ask questions to determine how much time to spend preparing to ask questions.

Sincerely,

Dan