This is so easy to answer! This post doesn’t even need more than just an intro.

It’s: reliably getting stuff done well. 🤝

It’s delivering (really emphasis on delivering) results of high-enough quality (it’s not about perfection, but about a rounded product, that is good enough for its users) and doing this in a timely manner and of course also not pissing off other people in the process.

Ok, so how does one reach this?

Does such a simple thing even need explaining?

Maybe. I don’t know. It’s hard to look into the minds of other people (not impossible, demands lots of effort).

Maybe what is obvious to me isn’t obvious to you or the person sitting next to you at work.

So, why not just spell it out? Then, we’ll all know more for sure.

Firstly, you need to get stuff done (junior level)

This is the absolute first thing you need to master.

It’s like any other skill you ever mastered. First, you need to actually tie your shoes, even if it takes you 10 minutes and the result looks like an octopus died on your shoes.

The first step is simply practising to get stuff done.

You don’t have to know everything

An essential part of getting stuff done is learning how to get to the information you are missing.

If you are asked: “How many story points for task A?” you must learn to be comfortable when saying: “I don’t know yet, I need to research this. Let me research this for X story points, and I’ll come back with a proposal (or two).”

This step is about 2 things:

• learning how to do lots of things and
• learning how to figure out everything else.

How to access the documentation, how to read it, how to read the existing code, who to ask for help, what questions to ask, how to test assumptions, where to get user data, …. such are the questions you need to answer.

Secondly, you need to get the right stuff done (mid-level), don’t be an evil genie

We are all bad at explaining what exactly we have in mind and what we want from you.

Think of the many stories of an evil genie, who, to the dismay of the wisher, grants wishes very literally.

As in: the wisher wishes for 10 million dollars and gets 10 million Jamaican dollars (which is about 60k USD) or they wish for a dead person to be alive, only for the dead to come back as a zombie. Technically, the wish was granted, but the wisher is not happy.

Technically, your solution does work as described in the project spec, but it misses the point of the project.

Unfortunately, we have been lied to. Developers too, need social skills to be successful.

Thirdly, now invest in the quality of your work (senior level)

Now is the time to think bigger.

Think of all the ways your code will be used.

The code runs and does the right thing, but

• does it do it fast enough?
• does it use minimal resources?
• is it extendable?
• is it readable?
• does it fail gracefully?
• are you happy with the test coverage?
• is it secure?
• is it maintainable?
• …

Fourthly, do it faster (expert level)

Speed has 2: finishing work in a reasonable timeframe and cutting corners when needed.

You can’t take forever to finish the simplest of tasks

This one is partly about communication and partly about speed.

Speed is important because you aren’t working for free. Your working hour costs somebody a certain amount of money. The project you are producing is worth to them a different certain amount of money. There has to be a balance between these two.

You can’t have a PR open for days. Just merge it already. Or split it up and merge parts of it.

You also can’t work on the same ticket for days. Split it up if it’s too big. Surely you’ve achieved something in 8h or 16h, something that can be considered done?

The other aspect is communication with your “task manager” (=boss/customer). It is hard to be patient with somebody who has been working for a week on something you believe should have taken 2 hours.

It is on you and really only you (I’m not being mean; this is just the reality of life), to manage the expectations about how long something will take.

It must sound silly by now, but “under-promise and over-deliver” is a good guideline. Everybody has a limit on how long they are willing to wait for you to do the thing. While they wait, all they have is your promise that “things are moving”.

The second guideline can be: “communicate early and often”. This was the whole point of agile development. Just tell people what you are doing and how it’s going, so you can adjust your expectations together and possibly even cancel or change the project. It’s about giving people the power to make decisions.

Don’t over-engineer just because you can

This is a hard one. Once we (devs) know how to build complex, pretty systems, it’s hard not to build them.

Yes, the code could be even more efficient, even more readable, even more extendable, even more secure, even more sleek, … but does it have to be?

If you have only 10 users per minute, then don’t optimize for 1000 users per minute.

If you don’t have actual plans to translate your app, then don’t build it with localization support.

Don’t extract code patterns, if you only have 1 use case.

Make an effort to use the simplest tool for the job. The more you have seen, the easier it is to overdo it, so, you really have to remind yourself to keep it simple.

Lastly, aim for cooperation, not domination (unicorn level)

It doesn’t matter how smart you are (or think you are), you would get more things done if you had a team of people behind you.

“Soft power” is not just for politicians. Your goal is for people to want to help you because controlling people is way harder than the movies make it out to be.

Our main adversary at this stage is our self-confidence. Converting confidence to arrogance doesn’t require much effort, but it kills other people’s goodwill.

One way to be destructive is to critique everything. Poke holes in every plan anybody ever proposes. No need to come up with a better idea, just point out the flaws of every motion.

Another is to be dismissive or argumentative when receiving criticism. If somebody brings forward a problem, you don’t win by convincing her the problem doesn’t exist, you win by addressing the problem. Listening to somebody is not as dangerous as some think. It generally does not harm your “identity” or endanger your position or influence.

Focusing on “my way” is the perfect approach to get people to shut up and do nothing, but the absolute minimum required. Contributing no new idea, no improvement. Moving nothing forward.

Cooperation over domination.

There is a catch though.

Unfortunately, this step is not equally easy for everybody. People do carry prejudices with them. So, if you don’t fit one of the cliché categories of a successful developer, then you will have a harder time winning people over. I haven’t found a solution for this yet…