You want some free leadership advice? You build yourself by buildingā¦ by helping others. The selfless act of helping humans will teach you more about being a credible leader than any book.
Your career is not your job. Itās the humans you help along the way.
Continue to the full article
→
Dependencies seem to be all around us, both in the real world, and in programming. And they are perniciously distracting in just this way. Have you ever noticed how rare it is for you to just do something?
If so, you might have been worrying, up front, about dependencies.
Being a senior developer means you spend most of your time stressed out about the optimal way to get something shipped.
But I donāt just see that stress manifest in my professional life. Ask my wife how many side projects around the house she wants me to do that have not even been started.
Itās why I admire people who just start projects with no fear.
And itās a trait I find myself trying to instill in my children, who will naturally jump into a task with both feet and zero regrets while Iām impatiently hovering over them, fretting about āsafetyā and messes thatāll need to be cleaned up.
Continue to the full article
→
The best frontline eng managers in the world are the ones that are never more than 2-3Ā years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.
And the best technical leaders in the world are oftenĀ the ones who do both. Back and forth. Ā Like a pendulum.
Continue to the full article
→
I saved my company half a million dollars in about five minutes. This is more money than I've made for my employers over the course of my entire career because this industry is a sham. I clicked about five buttons.
Oof, this is a very good read that hits pretty close to home. Iāve seen stuff like this in several organizations Iāve worked with.
I wonder why itās so prevalant?
Continue to the full article
→
āBut,ā you say, āpremature optimisation is the root of all evil! Duplication is better than the wrong abstraction! Donāt be an architecture astronaut!ā
The developers Iām thinking about already know of all those takes and have internalised them long ago. They know that sometimes āgood enoughā is the right choice given the constraints of a project. They know that sometimes you need to cut scope to stay on-track. They know that sometimes itās better to wait to learn more about a domain before rearchitecting a system. And yet in spite of those constraints their output remains golden. These are hard working motherf*ckers whose diligence and perseverance put other devs to shame.
Other devsā¦ like me.
Sometimes, I just CBF.
Continue to the full article
→
Iād like to offer a tool to put in your emergency kit for shifting self-sabotage to self-care and going from overcommitted to well-resourced. And that is managing for whole capacityārather than simply time or money. In other words, donāt ask, āCan I squeeze this in?ā when presented with an opportunity. Ask, āDo I have what I need to do this well?ā
Continue to the full article
→
Saying āuse the right tool for the jobā is easy, but actually selecting the right tool for the job is anything but. Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings.
But thatās all part of the work.
And if you ājust use Goā or ājust use Reactā or ājust use Postgresā for every problem that crosses your keyboard, youāre just not putting in the work.
Iāve only worked in agencies my entire professional career, and that work has honed two important traits of a good engineer: curiousity and agility.
Being curious gives you the ability to explore new tools and understand how they work.
Being agile (not in the project management sense, but the āmoving freely and quicklyā sense) gives you the ability to deploy those tools to solve increasingly complex problems.
Itās not that I donāt have a standard set of tools I reach for when solving a wide swatch of problems (Rails, Postgres, etc.), but as I get older, Iām finding that I am more willing to engage with newer tech.
I come from a background of writing Javascript by hand, but I'm starting to play more with Vue and React, and I can see why people like these tools.
Same thing with CI/CD pipelines. I always thought they were more fiddle-y and brittle than they were worth, but that's because I've generally been a lone wolf. In a team context, they are extremely useful.
If you keep hearing noise about a new technology, it's probably worth taking a look over the fence to see how that tool could be used.
Continue to the full article
→
Managers: If your job ladder doesnāt require that your senior people have glue work skills, think about how you were expecting that work to get done.
Glue people: Push back on requests to do more than your fair share of non-promotable work, and put your effort into something you want to get good at.
Our skills arenāt fixed in place. You can be good and lots of things. You can do anything.
Continue to the full article
→
Do I have the time?
Do I have the mental space?
Is this project aligned with my values and the change I want to create in the world?
Will it energize me?
I posted these questions here for a quick reminder to my future self, but you should read the whole thing to get clarity around how to answer these questions.
Continue to the full article
→
I read Good to Great a few years ago, but I admittedly never finished it. After hearing this interview though, you'd better believe I'm gonna go back and pour over it.
This interview with Jim Collins was absolutely awe-inspiring. Among the nuggets I took away from this episode:
You should strive to be a "Level 5 Leader", which means you are simultaneously headstrong and humble. You have to put your organization before any personal gain.
Jim organizes his time according to the 50/30/20 rule, which means he spends 50% of his time in a given 365 day period on creative activities, 30% of his time teaching, and 20% of his time on everything else.
On that same vein, Jim has a spreadsheet where he tracks how many hours a day he gets creative pursuits, and in any given 365 day period, he has to have over 1000 total hours. He also tracks what he did on a given day, as well as a rating from +2 to -2 for how he felt on that day. I've been trying to do something similar with tracking the big three things I need to get done each day, and I think I should expand that out a little bit to include these variables.
You should not do what youāre good at, but do what youāre coded for. This really struck a chord with me, because I think I'm pretty good at developing, but I'm pretty sure I'm coded to be a leader.
There was a lot mentioned around the flywheel principle, and I think this is something we're just starting to see happen with our own business pursuits.
There's a ton in this episode, so I'm going to stop writing in order to let you start listening.
Continue to the full article
→