š a linked post to
youtu.be »
—
originally shared here on
Leave it to Cal Newport to show up in my algorithm and give terminology to part of the struggle Iāve faced for several years now: deep procrastination.
Deep procrastination is when youāre physically unable to work up the motivation to do work that needs to be done. Even with external pressures like deadlines, your body is unable to find the drive to do the thing.
This is different from depression because deep procrastinators were still able to feel joy in other areas of their lives, but not work.
He also mentions dopamine sickness, an effect from being constantly rewarded by quick hits of dopamine for an extended period of time.
If you are dopamine sick, you are unable to focus for long periods of time because your brain is literally wired for short term wins, not for deep, difficult thinking.
His solutions to both of these problems are infuriatingly simple: use an organizational system to handle doing these tasks, make hard tasks easier, use time boxing, remember your vision for your life and aim your work toward that.
In the video, Cal says, āwe appreciate hard things when we know why weāre doing them.ā It reminds of the episode of Bluey called āRagdollā where Bandit agrees to buy the kids ice cream only if they are able to physically put his body into the car to drive them to the ice cream place.
After a series of mighty struggles, Bluey is finally able to take a lick of an ice cream cone and is instantly greeted with a moment of euphoria, made possible only after all that hard work.
There are several pieces of content that Iāve consumed today which are all colliding into one potential blog post about how Iām deciding to be done with my crippling anxiety. Maybe after this video, Iāll pull out my laptop and start some deeper writing.
š a linked post to
mcfunley.com »
—
originally shared here on
I saw this article referenced while reading Bill Millās recap of relaunching a website, which in and of itself is a delightful read for those of us who nerd out on large-scale system architectures.
I am almost certain Iāve read Danās piece on boring code before, but I wanted to share it here because it serves as a great reference for those of us who are sick of making bad tech stack decisions for bad reasons.
In particular, the ending here sums up my experience consulting with many different tech teams:
Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.
Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.
The teams which move the fastest are the ones who are aligned on a vision for what is being built.
Often, these teams hold a āstrong opinions, loosely heldā mentality where they decide what tools theyāll use, and theyāll use them until they no longer solve the problem at hand.
Put another way: in a business context, experimenting with your tooling is a huge organizational expense that rarely yields a worthwhile return on investment.
Your focus should be on what you are building rather than how youāre building it.
A long time ago, a manager friend of mine wrote a book to collect his years of wisdom. He never published it, which is a shame because it was full of interesting insights. One that I think a lot about today was the question: āHow are you paying your team?ā
With this question, my manager friend wanted to point out that you can pay people in lots of currencies. Among other things, you can pay them in quality of life, prestige, status, impact, influence, mentorship, power, autonomy, meaning, great teammates, stability and fun. And in fact most people donāt just want to be paid in money ā they want to be paid some mixture of these things.
When I was in college, the phrase āitās all about the perksā became something I ironically said often when people described their jobs.
Iām realizing as I get older just how true that axiom is.
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.
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.
š a linked post to
charity.wtf »
—
originally shared here on
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.
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.
ā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.
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?ā
š a linked post to
changelog.com »
—
originally shared here on
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.