How to code like a boss?

#kiss #coding #testing

Simple, allow yourself to code like a boss!
Honestly you are the problem! Not the tools, not the language, not your boss, you are!

Ok there is one exception to this, if you're stuck at your job, some of this may be out of your control. But is all other cases, you are in control!

TL;DR

Get annoyed and fix what pisses you off
Experiment and learn what can be done better
Get the right tools and use them
Use the language as it's intended
Does what others do work for you?
Make your boss work for you

Ok let's go!

Allow yourself to be pissed off!

I recently had to start using Windows again... and boyo does it fucking suck! Windows 11 is the worst and I have been fuming on a daily basis by its sheer incompetence. And yes I could consider them as minor annoyances and just accept them... but I won't... and nor should you!

Allow yourself to be pissed off at software that doesn't do what you want it to, curse and scream at your monitor! And use that as an indication to ask: is it PEBKAC? Or is the software just utter crap?

Change what you can to get rid of annoyances because these are the core reasons why you're not coding like a boss yet.

If your Windows automagically switches your keyboard layout from UK to US or vice versa, remove the layout that pisses you off... or use not-windows
If your IDE is really slow, figure out why and uninstall the plugin that is sending all your data to $bigbrother
If your unit tests fail because someone made a change, sit down together and figure it out
If your boss doesn't let you experiment to improve your skills/efficiency, find another boss

And related, consider the ergonomics. Is your desk, chair, computer, laptop, screen, mouse and/or keyboard up to snuff? If you wanna be good, you're gonna be doing this for a while so ensure your body is gonna hold up in the longrun.

Experiment

Just because you've always been doing it like that doesn't mean you have to keep doing it like that. As a matter of fact I really really... really fucking hate that mentality!

So the other day I decided to do yet another new experiment: does Neovim and Go make me more productive? Thanks @ThePrimeagen for giving me another hobby I could do without! Did I need to do this? Nope... not for my job at least... but did I want to do it: HELL YES! I love trying out new things to see if it can either help me improve my own skills or allow me to be more efficient... or inspire others!

So what am I trying to prove? Are there better editors/IDEs out there and is there a language better suited for what I do? I do this shit on a regular basis, whether it's getting a different keyboard, trying a new language or dicking around with automatic provisioning... I just want to get better.

There are very few things more effective than experimenting because you fail continuously... failure == good! It allows us to learn, the more you fail, the more you learn (assuming you accept your failures).

Choose the right editor/IDE

Just because someone tells you VS code is great, doesn't mean that it is... or isn't. You need to find out for yourself what works and what doesn't.

When I'm behind my desktop I don't want to let go of my keyboard because moving my arm 10cm to my mouse and back feel inefficient and potentially ergonomically problematic. So in this case I want to use an editor/IDE that allows me to do everything with my keyboard. I've also extended this to my browser with spatial navigation. Then again if I'm on a Macbook I'm less bothered by this as the touchpad is so damn fantastic. That said in the end I still prefer a split keyboard + no mouse when coding for more then an hour.

I've used a lot of different editors and IDEs and even the ones that sucked terribly have been a worthwhile experience. I'm not saying one is better than the other, I've always enjoyed coding and the tools were the enabler. But I have matured and with that realised what the enjoyment of coding is... the coding! Anything around it is just an enabler and should STFU unless spoken to.

Automation is key

Over the years I've convinced myself I've become a better coder. Regardless of whether that's true I've automated the hell out of my dev work so I can focus on coding (and yes, I do see the irony). If I press "save" on my code, within a second I know for a fact how good or bad my code is and whether I can push it up.

How?

Syntax highlighting, because duh!
Linters & Formatters, let your editor handle that shit
Automatic test runners, :w -> see unit & integration tests purrrr... for a second
Code coverage, fuck the statistics, but seeing which lines aren't tested means you can make a split-second decision on whether to care
LSPs, instant feedback on your code is wonderful
Scripting, Bash is wonderful and even though I was sceptical I'm starting to see the benefit of Lua in Neovim
Version control, knowing what changed is half the battle, merging and rebasing is the other half
AI, Copilot and others are an enormous time saver, especially when you're doing more of the same. That said, with learning Go I've realised that, although a big help, I still yearn for the documentation to really understand how things work. In coding understanding why something works makes you better, not copy/pasting a solution from stackoverflow (or having a LLM do it for you).

Note that CI is crucial in the next phase, whether in a pipeline or as a pre push hook, ensure you run automated code & security scans, end to end tests, builds, rebase checks and any other automated check that could potentially prevent your PR from being merged

Use a proper OS

I don't care what you use as long as it doesn't need a reboot every other fart and actually does the thing it needs to do when you want it to. I'm not saying install $linux_distro or go buy a Macbook but consider this:

Every second wasted on twiddling your wiener because you have to wait on something, is a second not coding as a boss

What's the best language?

Well as per usual: it depends. Just don't think for a second your language is a Swiss Army knife. But... feel free to try it and fail because that is a valuable experience... again, assuming you acknowledge your failure.

I've used quite a few languages, some I hated... some I hated even more... I even attempted to create my own at some point? Why? Because Bash is such a shit show I wanted something... less shit. It was called... KISS for obvious reasons. But I ended up abandoning the project when I bumped into CoffeeScript as that was super close wrt syntax and package management. It just wasn't a Bash replacement, but who cares I had a new toy!

And now I'm enjoying Go, because? I don't know it just feels right... everything I want to do just works as I expect it to. Kudos for Ken, Rob and Robert for really nailing it. But that just means it's a good language for me. I've fought with too many languages over the years and in the end it may mean you're not gonna be friends and that's ok.

Back to lesson 2: experiment, try out a couple languages... build a side project in some language and figure out what you like and hate about the language. For example, I've always hated interfaces, they seemed... reversed... and guess what? Go flipped them around and they're amazing! Equally Bash as a language is wonderful... to a certain point... once you reach that point: stick everything in /dev/null and walk away. I found out by experimenting with multiple languages why I didn't like them and how and when they can be useful... and most importantly: fun to code in!

More brains == smarterer

It doesn't matter how smart you are, the collective brain knows more. Talk to people, do pair programming, listen to senior engineers, listen to junior engineers, DevOps, QA and Database engineers. They will all have interesting stories and experiences that you can learn from. No point in falling into the same traps as they did... well actually, in some cases it is essential to fall flat on your face as some things can't be taught.

You can learn a lot from other people and how they solved things and you should use that to push it to the next level, stand on the shoulders of giants and all that... but also try to understand what and why they did and not just accept that what they did is right. Really understanding the layer you're building on, helps you to build things better.

The hardest thing is probably accepting that what you build is shit... whether it's someone else showing you the light or you come across some project that does what you're building but better, do a final commit & push and stop. But it was not a waste of time tho! You have learned a lot and you can use that in your next project... for which undoubtedly someone comes along to tell you it's shit, so you know... fuck other people's opinions!

Make your boss work for you

Your boss has 1 job: enable you to be as efficient as you can be. And contrary to popular belief this means your boss needs to invest in you. Obviously there isn't a money tree growing in your company but investing a couple bucks can create an enormous efficiency gain. Consider your boss gives you a crappy chair, desk, laptop, mouse, keyboard and which saves the company $2000 one-off. You get a problem with your back and guess what, 1 month in and the company already wasted more than they saved because your productivity went down the drain.

But you are the one that needs to make your boss aware. You feel the physical pain and/or mental pain of the inefficiency, your boss doesn't. Your boss just doesn't understand why shit's taking so long. If you have great boss they'll regularly check-in to see how they can help you being an even better version of yourself, if you have a good boss they help you when you ask them and if you have a terrible boss they ignore everything you say. In the latter case, find another job. In the former cases, understand what pains you (and your team) and help your boss enable you!

One of the guys in my former team kept harassing me to go to Slack because Teams was shite. And while I felt his pain as well, it was his tenacious attitude that convinced me to get budget and get it sorted. It was one of the best moves for him and the rest of the team.

Conclusion

Whether I'm coding like a boss or just feel that I do, it doesn't really matter. What matters is that you make the miles. You don't get good at something by staring at it or letting others/AI do the heavy lifting. If you want to be a boss, do the work! Try new things, stick with it for a couple years, learn, move on and rinse and repeat.

And take your time! It's not gonna happen overnight and it's not gonna happen by itself. But above all: enjoy coding!

My ever-growing list of editors

Norton Commander & PE2, thanks to my dad for having this setup back in the day as it helped my managing that shit ton of BATch files when I was about 10...
- Fuck... I just realised I've been doing shell-scripting for 30+ years 🤦
Notepad / Notepad2 / Notepad++, this is fine...
Borland C++, it was really good back then... not sure how well it aged tho
Visual Basic, I can only remember a lot of buttons that didn't really work and you ended up doing it in code... in true micros~1 fashion
Borland Delphi & Kylix, I wasn't overly impressed but it did the job... Kylix (aka run Delphi in wine) was terrible tho
Vim, I've spend a lot of time in Vim and we go way back! Yet I did abandon it
Atom & Sublime, I wasn't happy with Vim, so you try things... good things... bad things...
VS Code, This is what I settled on after Vim... why? It did things... a lot of things and unlike many other micros~1 products it did them well
Neovim, and here we are... back to Vim... or maybe I'm secretly longing for PE2?