Say, for instance, you are given a seemingly impossible task, that over the next thirty days you are to be twice as good as you are today. How might you accomplish that? Would you break it apart? Try to focus on the most meaningful changes first? Tackle them one at a time, perhaps utilizing some sort of list? Congratulations, you might be an engineer. Would you instead, shift uncomfortably in your chair, attempt to point fingers at others, pretend you’re doing fine, and quietly start looking for a new job? Congratulations, you’re an asshole.
First, let me say, that the goal of attaining the unicorn status of the 10x programmer is probably unattainable, but 2x is definitely within your grasp.
Improve your basic skills
The 2x speedup is not, I repeat, NOT from a new language or toolkit, it’s from mastering the basics. Using Angular instead of static html pages does not make you a better programmer. It’s possible, that once mastered, you can be more proficient in setting up rich, responsive and scalable single page web applications, than you would using a simpler toolchain, however this is not going to help you attain 2x in the next thirty days, so don’t waste your time. I don’t mean to pick on Angular, it could easily be React+Redux or any other such framework-du-jour. The point is that there are better uses of your time.
If you were a chef you would practice knife skills
If you were a ninja, you would practice nunchuck skills.
If you were a hairdresser you would practice cutting doll hair.
Why would software be any different?
Master basic keyboarding Skills
- Do you hunt and peck?
- Can you navigate your OS / Editor without your mouse?
- Can you type quickly and accurately for sustained periods of time?
- Did you know that holding control while moving left and right can advance a whole WORD at a time. Magic!
- Have you learned the joys of Ctrl+A and Ctrl+E instead of home/end?
- Seriously, rebind that shit. Your life will change for the better.
- You don’t have to go full emacs or vi binds, given the learning curve, but that could be a worthwhile long-term goal.
Set aside time to practice programming
Do it on the company dime or not that’s up to you. The point is to seek measurable improvement.
- Write a function.
- Now delete it.
- Write it again.
- Delete it.
- Continue until the function is perfect or your boss notices what you’re doing.
If you’re not willing to invest in yourself, then why would anyone else?
Do not decry your company for failing to provide you with adequate tools. Go out, find the tools, and if your company won’t buy them or approve them quickly buy them yourself or LEAVE.
Practice Taco Bell Programming
functionality is an asset, but code is a liability.
There is of course, value in re-inventing the wheel, but only to learn more about wheels. In the next 30 days, you have no such luxury. Work smarter, not harder.
Pick the simplest solution that could possibly work, test the hell out of it, and move on. My colleagues don’t have the luxury of the beautiful Linux tools that the author talks about here, but we should at least learn the lessons the Unix way. Make small composable units and combine them to make even more useful units. Repeat until you are the master of the universe.
Okay hopefully the non-nerds didn’t make it this far, and they don’t think to read up. I want them to take this seriously too, but honestly, nerds, realize your value. You are more vital to the company than they are. Now that you know that, stop being cowed into doing things by people just because they talk loudly at you or as “are you sure?”. These are laughably transparent attempts at manipulation, and they shouldn’t work on you. Man (or woman) up and do something about it.
My scrum master said that we’re behind schedule
My scrum master said she was going for coffee, anyone want one?
PS: It wouldn’t kill you to write a few tests too. Code fearlessly because you’re backed by tests
Don’t think I forgot about you. This concerns you too. If you would like to help these nerds achieve their dreams of literally doubling their output, and attain all the moneys that you so desperately want, then could you please do the following?
Understand the power dynamics, and stop abusing them
My favorite programming joke of all time goes like this:
How can you tell if you’re dealing with an extroverted programmer?
(pause for dramatic effect)
He’s staring at YOUR shoes!
(hold for applause)
Why does this joke work? Because it’s true. I touched on it perhaps a little too softly last time, so I’ll spell it out in no uncertain terms. Programmers are, generally speaking, afraid of confrontation and really bad at communication. If you take advantage of this fact, not only are you a terrible person, but you’re also doing yourself a disservice because again, you have no idea how this shit works.
If a meek expert tells you it’s going to take several days because of the [a bunch of shit you don’t understand], and you say: “Have it in by tomorrow”, they will likely not argue. You have just torpedoed your own project. Stop it.
Stop Breaking My Flow
Flow is great.
This post was conceived and authored in a single day. Granted, it has been brewing for the last 10 years or so, but today was the day that it became manifest because I had a long swath of uninterrupted time to compose my thoughts.
If you stop interrupting people, they will produce double the output in half the time. They’re on a different schedule than you are, and you should respect that, or at the very least understand it. Maker Schedule vs Manager Schedule
Armchair Psychology 101
Freakanomics reminds us that people respond to incentives, but rarely in the way you expect. You cannot just pay people more money and expect better outcomes. In fact, you actually get worse outcomes.
Axiom: People are willing to work harder on something they care about, the quality is better, and they tend to stay at companies where this is true longer.
Sadly, you cannot force people to care, but you can trick them into it. Much like smiling to fool your brain into thinking you’re happy, you too can manipulate others to achieve your financial goals. Bonus: it’s good for them too.
- When they make something you like, praise them.
- When they make something you don’t like, tell them how they can make it better.
If you consistently pretend that the work they do matters, they might just start believing it.
One of my most rewarding work memories happened on a conference call to some vendors I had never met. The business owner I had been developing for said the phrase “They’ve built us a wonderful tool”. It took a handful of seconds and zero effort on his part, and it motivated me for months. If you can’t do this, you’re a bad leader, or a sadist, or both. Shout out to Matt Watters, wherever you are.
Mythical Man Month
If you are a project manager, scrum master, product owner, program manager, middle manager, release manager, delivery manager, and you have not read this book, you are wrong.
This is required reading for anyone in the software field, but doubly so if you are in charge of any aspect of delivery.
How does a large software project get to be one year late? One day at a time!
TLDR here are the cliff notes:
- Software projects fail a lot.
- More people slow down a project.
- Estimates are hard.
- Fixing bugs often results in more bugs.
I think that’s everything. As always, please don’t fire me.