[HN Gopher] Professional Programming: The First 10 Years
___________________________________________________________________
Professional Programming: The First 10 Years
Author : keegancsmith
Score : 116 points
Date : 2022-05-17 08:22 UTC (2 days ago)
(HTM) web link (thorstenball.com)
(TXT) w3m dump (thorstenball.com)
| troelsSteegin wrote:
| "Code has mass". Following from that, attention is force and
| understanding is acceleration.
| dokem wrote:
| I think understanding would be velocity. Acceleration would be
| change in understanding, which is proportional to attention.
| nh23423fefe wrote:
| No I dont think that follows. Forces don't cause accelerations.
| But attention is required for understanding.
|
| > Every additional line of code you don't need is ballast. It
| weighs your codebase down, making it harder to steer and change
| direction if you need to
|
| So code as mass is the scalar part of the momentum. So the
| directional part is where this code is going in "purpose
| space".
| kqr wrote:
| Code has mass has another interesting corollary: large enough
| collections of code tends to almost gravitationally attract
| more code. This results in god classes and those huge libraries
| of diverse functionality that usually go by the name "misc" or
| "util".
|
| The mechanism for this is fairly obvious: it is usually
| convenient to put new functionality next to existing one
| because it allows you to reuse things that maybe should not be
| reused. The more diverse a big lump of code, the more potential
| future functionality is convenient to add to the lump.
|
| This is a reason to be very vigilant against this type of
| accidental reuse and incohesive modules. It's a reinforcing
| feedback loop that needs a balancing mechanism.
| kderbyma wrote:
| Always leave something unfinished at the end of the day
|
| --
|
| definitely helps me get focused the next day
| lysecret wrote:
| Really enjoy the fearlessness. I wanted to share my main guide
| for programming, my dad always told it to me it comes from
| KentBeck: First, you make it run. Then you make it right.
|
| It is a bit connected to fearlessness, because you need to be a
| little fearless to start something without knowing where it will
| go. I think fearlessness originates from a trust in oneself, and
| maybe the universe too haha
| civilized wrote:
| 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 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.
| AnimalMuppet wrote:
| People are emotional, at least to some degree. Most people find
| emotions contagious. If you're surrounded by people being
| negative, it's _draining_ , even if you don't give in to the
| negativity.
|
| 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.)
| misternugget wrote:
| Author here. Just wanted to add that I don't think all forms
| of snark, sarcasm, and cynicism are bad. Or even negativity!
| But what I learned the hard way is that there's a time and a
| place for this and often it's not "your team & whenever
| something pops in your head". I very much agree with the GP
| here in that I value mindfulness when it comes to negativity.
| civilized wrote:
| I just wanted to say I loved your post and I think this is
| a very hard thing to articulate in our culture. Because
| you're absolutely right about the social impacts of many
| forms of negativity. But "negativity" seems too broad of a
| term for the thing we need to avoid. But then, what is the
| more precise alternative? I guess "mindless negativity" is
| something closer, at least.
| civilized wrote:
| On the other hand, if you model productive negative thinking
| and communication, people will be relieved that they have the
| space to express their problems, and you will accelerate
| genuine team bonding and psychological safety.
|
| I have success stories from my personal experience doing
| this.
| chrsig wrote:
| I think some big things to consider is what the negativity
| is trying to accomplish, how is it presented, and is any
| solution presented?
|
| Is there vindictiveness in the negativity? resentment?
| superiority? smugness? irritation? is it directed at a
| person, a process, a project?
|
| Is the negativity being brought up just for the sake of
| complaining? to solicit empathy or solidarity?
|
| Is the negativity specific? actionable?
|
| Those may be valid feelings, and great things to
| examine...and then probably keep to yourself, and find
| productive ways to either soothe/cope or change the
| environment/root causes.
|
| I say this as someone that endeavors to do what you've
| described in your initial post, but also as someone that
| struggles with adhd/depression, keeping it to myself can be
| it's own struggle. And then I worry that I've rained on my
| coworkers parade, or that I've worsened their work
| environment.
|
| People have something of a battery when it comes to this
| sort of thing, and it can definitely be drained, so it's
| important to be conscientious of that.
|
| Mindfulness exercises and meditation help me a great deal
| with all of the above, by doing what you suggest, and being
| inquisitive about the feelings. And also being aware of how
| the body is behaving during those feelings.
| civilized wrote:
| Yeah, doing negativity right isn't easy! It's essential
| to look inward for how the expression might impact
| people.
| ilrwbwrkhv wrote:
| This is very well said. I am trying to practice this myself as
| I find myself to be very mercurial. I have been going through
| the book living untethered by michael a. singer to guide the
| way.
| derekstride wrote:
| > Look at that little program go, holding the internet together,
| despite the 17 TODOs in it.
|
| This hit a little too close to home.
| ctvo wrote:
| > 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.
| robervin wrote:
| Absolutely agree, but I like to think the magic bit can stick
| around as wonder. Perhaps that's bundled into deep curiosity.
| humbleMouse wrote:
| This is what I tell anyone trying to learn programming or any
| computer related craft. The first step is to not be afraid of
| the computer. Only then you can learn.
| albertzeyer wrote:
| I observed that many people are really afraid even of basic
| things. "I don't want to click here because I don't know what
| it does. Maybe it breaks my computer or deletes all my stuff."
|
| 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.
| kqr wrote:
| It goes deeper than this. It's not just about trying things;
| some people do the opposite: they try too many things at
| once.
|
| The real skill lies in trying things systematically,
| carefully, querying your mental model of the system and
| invalidating hypotheses along the way.
| gombosg wrote:
| You mostly can't break computers, except when stuff actually
| breaks in production and it hurts users/customers a lot. And
| thus we have engineers responding to incidents and writing
| postmortems. :D I have learned a lot from alert and incident
| management!
| jrvarela56 wrote:
| 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
| 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.
| ctvo wrote:
| > 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 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.
|
| 1 - https://en.wikipedia.org/wiki/John_Carmack
| afarrell wrote:
| That definitely relies on a lack of deadline pressure...
| which is really about knowing that your team lead trusts
| your judgement in how you allocate time.
| gombosg wrote:
| Awesome article!
|
| > Typing can be the bottleneck Agree! Learning touch typing (at
| 30 :)) was a big relief for my fingers and wrists. Also it's
| important to have a good mechanical or scissor keyboard so that
| typing actually feels good.
|
| > Hiring is hard And it's like dating: you only get to know the
| people who you actually hire and never learn what would have
| happened to the people that you have rejected. That is some
| selection bias in the system.
| danielvaughn wrote:
| 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 behavior if need be.
| gryn wrote:
| A lot of the time it's not characteristics of the code itself
| but the business mission it needs to fulfill.
|
| 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.
| calderwoodra wrote:
| Amazing post, thanks for putting this together.
|
| Three points I think are undervalued in my experience:
|
| > Typing can be the bottleneck
|
| > The most important trait in developers: rolling up their
| sleeves because it has to get done
|
| > Nothing really matters, except bringing value to the customer
|
| I often feel the code needed to deliver value is not that complex
| and most senior folks can do it, but in an effort to "save time"
| on typing, they try to design something complex and debate
| endlessly, when what's really needed is rolling up your sleeves,
| getting it done, then saying "oh that? I finished coding it and
| it works, let's ship it already"
|
| (edit: formatting)
| terrycrowley wrote:
| Great article. The point about fearlessness resonated. Ray
| Tomlinson (wrote the first inter-machine email, picked the @
| symbol, helped design TCP) was one of the best and most fearless
| engineers I ever worked with.
___________________________________________________________________
(page generated 2022-05-19 23:02 UTC)