11–20 of 34 posts
> Fearlessness is undervalued Being technically fearless is also a trait I've identified in engineers I enjoy working with. It's hard to quantify how you gain this. I think it's a combination of strong fundamentals and deep curiosity. It forms when things stop being magic.
"Code has mass". Following from that, attention is force and understanding is acceleration.
> Fearlessness is undervalued Being technically fearless is also a trait I've identified in engineers I enjoy working with. It's hard to quantify how you gain this. I think it's a combination of strong fundamentals and deep curiosity. It forms when things stop being magic.
Maybe it's because I started using computers as a child (~9 years old or so) but I always had the mindset to just try things out. You cannot really break the computer or delete stuff. Every tool will always put a very clear warning before you do sth stupid. And if you are really unsure with some action, just make a backup before. Reinstalling Windows every so often was anyway the norm in my youth.
And just trying things out, clicking through the menu, through the actions, just playing around, make some dummy playground, this is often how I discovered the functionality of most tools. This is a very effective way to get familiar with most tools.
But others, when they say they don't know how to do X in tool Y, they never have just tried around. And when I ask them why they have not, they tell me that they are afraid of breaking or deleting sth.
With coding, it's very much the same. And now that we have Git, with some backup somewhere remote, and hopefully a test suite, maybe even with CI, it's even much less of an issue if you break sth because it always can be undone and you normally should notice with the tests (or if you don't, you can blame the incomplete tests).
Btw, regarding reading other code bases: I very much can recommend that. You will most likely learn a lot. And there are many great open source projects where you can just dive in.
The point about other people's code rings true for me. What I've been trying to do is gather a collection of good code I've written over the years - solutions that can work for a variety of problems. They're like my own little npm packages, except I have full access to the source and completely understand them inside and out. I can also completely explain how they work to my team, and how they can make changes to the…
good code can give you a lot of headaches if the external business environment sees qualitative changes while that sloppy code over there is has being going hassle free for the last 6 years because the end-goal and patterns that it needs to fulfill didn't change much during that period.
> Negativity begets negativity
I think this is coming from a very common and fundamentally misguided premise - the obsessive focus on emotional valence, on whether we're being positive or negative. The real problem is not whether we are being positive or negative, it's the rush to attach emotional valence to things we have not adequately understood or described. As C. S. Lewis said, "the human mind is generally far more eager to praise and dispraise than to describe and define. It wants to make every distinction a distinction of value." This rush to emotional endpoints is the root of both toxic negativity and toxic positivity.
Instead of taking positivity and negativity as endpoints, take them as prompts to better understand your surroundings. You are feeling bad about something - why? What about it makes you feel that way? Would improving it cost more than it would benefit? Is it the least bad of the alternatives?
A willingness to feel and acknowledge and investigate your negative emotions is a superpower. It gives you x-ray vision into things that very few other people have. They look away from problems and let them fester because they've been taught to be allergic to negativity. The ability to look at problems is inseparable from what the author points out is a very important trait, the ability to roll up your sleeves and get stuff done.
> Fearlessness is undervalued Being technically fearless is also a trait I've identified in engineers I enjoy working with. It's hard to quantify how you gain this. I think it's a combination of strong fundamentals and deep curiosity. It forms when things stop being magic.
An example is being comfortable reading a dependency's source code. Once you realize you can do this by going to Github/Gilab - or even navigating to where a function is defined via your editor - you realize it's all layers 'down' and you can go in there as far as you want. Another example is using dev tools to prettify the code (but it's rarely readable).
Another thing is the payoff: how often can you deep dive and make changes to solve your problem? This determines if the reading through a huge library is worth it.
Starts with curiosity but requires lots of time available and a bit of confidence that the endeavor could lead to a solution.
> Fearlessness is undervalued Being technically fearless is also a trait I've identified in engineers I enjoy working with. It's hard to quantify how you gain this. I think it's a combination of strong fundamentals and deep curiosity. It forms when things stop being magic.
I think it's a mix of curiosity, lack of deadline pressure - and something else I can't put my finger on. An example is being comfortable reading a dependency's source code. Once you realize you can do this by going to Github/Gilab - or even navigating to where a function is defined via your editor - you realize it's all layers 'down' and you can go in there as far as you want. Another example is using dev tools to p…
I'm not sure I agree on lack of deadline pressure.
There's a virtuous cycle somewhere if I squint that's fundamentals -> makes it easier to find where the problem is -> makes you more willing to dive deeper -> leads to stronger fundamentals. In parallel maybe, curiosity -> dive deeper reading other people's code / learning about software -> stronger fundamentals
This all leads to things like "I bet this is a network or protocol level issue in this dependency" -> even in someone else's large, open source codebase, I can quickly track down the problem without needing to understand the entire structure, for example. But gaining that ability to intuit takes time, especially for newer engineers.
Edit:
Technically fearless though isn't really the above example for me, it's more, if the business needs it, and we want to allocate resources, there's nothing I can't build or learn how to build in a reasonable amount of time. When you're layers and layers of abstractions up, you're constrained at each layer on what you're allowed to build. Perhaps a simple definition of being technically fearless is the ability to drop down layers of abstraction as needed to solve problems.
I think John Carmack[1] is technically fearless, for example. Known for video games, but I would hire John in any domain and have no doubt he'd be successful.
Earlier quoted context omitted.
I think it's a mix of curiosity, lack of deadline pressure - and something else I can't put my finger on. An example is being comfortable reading a dependency's source code. Once you realize you can do this by going to Github/Gilab - or even navigating to where a function is defined via your editor - you realize it's all layers 'down' and you can go in there as far as you want. Another example is using dev tools to p…
> I think it's a mix of curiosity, lack of deadline pressure - and something else I can't put my finger on. I'm not sure I agree on lack of deadline pressure. There's a virtuous cycle somewhere if I squint that's fundamentals -> makes it easier to find where the problem is -> makes you more willing to dive deeper -> leads to stronger fundamentals. In parallel maybe, curiosity -> dive deeper reading other people's cod…
--
definitely helps me get focused the next day
A lot of really good stuff here, for example reaffirming YAGNI and a focus on customer value. One part I think falls short: > Negativity begets negativity I think this is coming from a very common and fundamentally misguided premise - the obsessive focus on emotional valence, on whether we're being positive or negative. The real problem is not whether we are being positive or negative, it's the rush to attach emotion…
One think I would say the article is wrong on, though - snark doesn't have to lead to cynicism. At my place, we talk a fair amount of smack, but it's just entertainment. (One difference - the smack is self-directed at least as often as it's directed at any particular other person.)