Programming as Theory Building: Why Senior Developers Are More Valuable

 (cekrem.github.io)

61 points | by vinhnx 18 hours ago

5 comments

  • mcapodici
    9 hours ago
    I agree with the ideas at a high level, but not sure if we can tag people as “Junior” and “Senior” and make these broad strokes about how they think.

    We should think of it in terms of “Theory Builders” and “Just get it done-ers”, and think of them as states of mind, rather than a character trait, or something linked to years of experience.

    You may have a theory builder straight out of university (after all many go on to do a PhD straight away!), or a theory builder who has the mindset and just came in from a different profession. Or an 8 year old theory builder! You may have someone with 10 years experience writing code who still slings code.

    You may also have one person who was a Theory Builder on Monday, and became a "Get it done-er" by Friday due to a deadline.

    [-]
    • ffsm8
      7 hours ago
      Or the person that starts off in "get it done" mode because it looks trivial, notices that it's not and then takes a few steps back to think it through first.

      Honestly, these opinions are almost always grounded in people not being honest with themselves, feeling superior to their colleagues and coming up with a character trait and argument why they're just fundamentally better

      Sometimes they even are, at least to a degree. No idea wherever it's true in this case, as I know nothing about Christian Ekrem beyond this article.

      [-]
    • mjklin
      7 hours ago
      Among magazine staff there’s a saying about “senior editors”: senior to whom, editor of what?
    • the_real_cher
      7 hours ago
      I personally think one does a lot of the theory building while you're getting it done because you're building something new and can't predict the kinds of issues that youll encounter.

      Any sort of software that's architected only in flowcharts and uml by 'pure architects' are absolutely worthless to anyone but business people.

      [-]
      • gorjusborg
        5 hours ago
        I agree that there needs to be a feedback loop including the system and decision makers (I also have a distrust of non-contributing 'architects').

        However, just because you can 'get things done' in the current system doesn't imply you have a good enough theory for maintaining it sustainably. I've often seen self proclaimed 10x coders who trade healthy shared theory for mean time to deployment too aggressively.

        They are fast, get praise and pay, then move on before the negative effects of their short term strategy becomes clear.

        Another job of 'senior' devs is to point out to the business when this is happening.

  • dang
    9 hours ago
    Naur's essay is not about time spent in the field, which is what 'senior' usually means; it's about time spent on a particular team.
  • ngruhn
    10 hours ago
    I noticed that. If I don't write the code myself I only develop a very shallow mental model of what's doing. But I guess that always has been the product managers perspective.
    [-]
    • bryanrasmussen
      10 hours ago
      I don't think you need to write the code to develop a deep mental model of what's going on, but you do need to think about it a lot and intensely to develop that model and coding forces you to slow down, spend a lot of time thinking about the problem, and generally trying out different ways of looking at it.

      Coding in this way is like having a personal Socrates to help walk you through the problem and achieve enlightenment.

      [-]
      • mfro
        3 hours ago
        This is the way I feel as well. I think there is an ethical way of using AI as an assistant: have it either generate a high level plan for what the architecture of your solution should look like (and decide whether the choice looks correct for the domain and actionable), or let it generate the code and then walk yourself through each line, documenting the solution as you go. I will go as far as to do the latter and then delete the code, re-implementing it to make certain I understand the relevant concepts.
    • jalk
      8 hours ago
      The same thing happens with third party tools and frameworks/libs. The documentation very rarely help you develop a sound mental model of how it work, so your only option is to get your hands dirty - and often also burn your fingers in the process.
  • SamInTheShell
    10 hours ago
    Could’ve just explained it in less words.

    Junior dev: Make me a sandwich.

    Senior dev: We’re building a sandwich. It needs a roasted tomato, thin sliced, X mm in thickness. Add some bacon. I want mayonnaise but it needs to be feature gated.

    One sandwich later. . .

    Senior dev: where’s my bread man?

  • msgodel
    10 hours ago
    I reference this paper all the time, it completely changed the way I think about software.
    [-]