We Need Programming Mentors
paperless.blog
paperless.blog
I think the real problem is that we don't call the first 5--10 years of a developer's career for what they really are: an apprenticeship.
A lot of companies hire what are effectively a team of apprentices and hope that they will somehow figure things out as they go. They tend to learn a lot of bad habits from each other. They will make you money, because even a small amount of programming skill can earn you money in the short run, but their code will eventually collapse under its own gravity and need to be rewritten.
Apprentices need to be paired with journeymen to learn the craft. I have not met a single successful team that has not had at least as many journeymen as apprentices -- ideally even more.
----
This is incidentally also my issue with the leagues of consultants who have only ever done greenfield or nearly greenfield stuff. They learn to write stuff in a way that it's completed quickly and lasts maybe a small number of years. That's what they are rewarded for, so obviously that's what they will get good at.
The people I've met who are really good developers are those that also have followed a product from initial design throughout its lifecycle into decommissioning. They seem to have a more holistic picture of the factors involved in making stuff.
I get it. From their point of view I'm C, Objective-C, they're Swift.
Instead I spent my last years making sure the young engineers saw me arguing with upper management when I thought they were being short-sighted, calling out bullshit when I saw it. I hoped to leave them with a sense of their potential for self-actualization and a heightened responsibility for the product — not to just be passive go-fers.
I think they appreciated that more. The architectural mistakes they're going to have to make and learn from themselves.
There's a lot of mentorship opportunities out there, I am sure. Likely not a formal process of waiting in the rain for days, and cross-team mentoring is going to be rare.
So I've been looking for ways to submit PRs in places, hoping to glean some knowledge by the code review. It's almost like a Dialog [1]. Easier to be egoless when seeking out how to improve.
Otherwise, one is left with hundreds of bygone repos, knowledge from frameworks past, and no real context: missing tribal knowledge, rewrites, and experiments. Works in which, for a time, the code represented the relentless vision of a single mind's dream.
This might be the case at the FAANGs or maybe at a few corporate giants where you can retire in place, but my own experiences were that if you weren't reinventing yourself or making your own major career changes, by year 10 you could be near aging out altogether. And, while I haven't looked at the data recently, that matches pretty well with what I recall being told as a college sophomore CS student, IE: by our mid-30s, most of us would not be working as software developers.
I wish I could agree with you - it would be a fair deal if there could be a conversation about software apprenticeships, but my own experiences were that no one, and certainly not your boss, were there to mentor or guide you. It was bloodsport where you produce or perish.
This! I couldn't agree more. We inflate people's alleged experience too quickly and don't have enough real journeyman mentoring and guiding in many orgs in my experience. Too many unguided teams. Self-teaching will only take you so far, or it's a very inefficient, error-prone route to experience imho without guidance.
I read a lot of code and learn from the mistakes of others.
I think before I write, I write code slow, and it has fewer sharp edges.
And I always did that.
Somehow it just fits the narrative of an old person better.
I've always wondered if a paid product might work for this?
There seems to be an explosion of coaching platforms but they all seem very focused around life coaching or non-specific business coaching (where anyone can coach anything to anyone) as opposed to the very deep, concrete world of software development. I've seen code-review as a service platforms and found them interesting, but perhaps if I were offered a lower-touch paid mentoring or coaching (eg, speak to a senior dev who knows your stack for an hour a week), I would pay for it.
A note on the article:
> Some will say the art of programming has regressed, because we now use enormously more resources to accomplish the same things as before.
I've only produced software as an adult, but I've been consuming a lot of it since the mid-90s. Let me tell ya, whatever you think of software, it was worse back then. I seriously doubt programmers were producing much more in terms of functional and non-functional requirements (UX, security, performance, etc.) than they are now.
Comparing to the 90's is a complete strawman.
But keep in mind that this regression is not a constant smooth movement. Most of the time the field has been progressing into better results, while very few times there has been a giant and immediate setback.
The quote from the article does not mention a particular timeframe in which it has regressed, so where is the strawman, exactly?
> Developer productivity has been regressing for the last ~15 years, and execution-time costs exploded at the same time. The change is much more prominent if you take into account non-functional requirements (UX, security, etc).
> But keep in mind that this regression is not a constant smooth movement.
> Most of the time the field has been progressing into better results, while very few times there has been a giant and immediate setback.
Since you are judging me on my rhetorical rigor, where are the proofs to these claims? Any longitudinal study from the IEEE ACS, ACM, ASP, reputed universities, etc.? Maybe some interesting ratios on aggregate inputs (programmer time, payroll, etc.) vs. value created (stock price, profits, software revenues, etc.)?
Maybe so, in a narrow sense of the word. But programming is a craft, and crafts have been around for a very long time, possibly for as old as homo sapiens (a definition of which is, the ability to make tools).
Programming is more like woodworking/cabinetmaking than "engineering".
Crafts used to be learned by hanging around masters for a long time ("companions" in France). It builds on experience much more than on theory.
So yes, mentoring is probably a good way to do the same.
> Programming using text editors with no knowledge of the code base was a big mistake, because it leads to other mistakes like trivial typos and trying to do refactoring using regular expressions.
Hear me out, but could it be that your mistake is actually using dynamically typed languages?
Also when you do a job it is not always the case that you can pick what language you're using so your solution doesn't make sense even if he was referring to dynamically typed languages.
In C static types exist, but type coercion means you can shoot yourself in the foot if you wish to.
What I meant above is not that Haskell and Rust are dynamically typed. That’s an error on my side but that the types are inferred. Left for posterity.
To be strictly accurate, Rust and Haskell both have strict type systems. It's just that like you mentioned, the types are often inferred at compile time via type inference rules.
This differs from dynamically typed languages as inferred types always have a statically known type while dynamic types have a type which is interpreted at runtime and which can be reinterpreted.
But yes, you are correct. The comment you replied to does not make sense. Haskell is not dynamically typed at all. (Though as with any statically typed language, you can create a Grand Unified Type that stores everything and pretend it's dynamic.)
What I meant was that types may be inferred but that is not the same as dynamic typing.
Overall, "strictness" is a really bad word to use, because it has thousands of different meanings. But on the context of types, I don't know of any better synonym.
Ah yep. Meant static there and fumbled my words. That's what I get for browsing HN first thing in the morning before coffee.
Now, I admit, I find programming with autocomplete more productive in general, but the compiler (and the compile time type checking mechanism) is still indispensible.
Sure, I don’t have to run the program to find the fault - but I have to run the compiler. And then parse its output and find the line it’s telling me about.
In an IDE, such feedback can be immediate, in place, and point me to the symbol where the error is evident.
I'm personally not there yet, but the way I've seen advanced programs write code is more akin to writing whole paragraphs at once and then relying on the compiler to catch any typos or similar trivial mistakes.
I want to write better quality code: less fragile, easier to change. Which is something I haven’t really done for one reason or another. Now, to level up my development skills, I just finished reading Philosophy of Software Design, Clean Architecture, and Design Patterns. I guess Stackoverflow is a good place for me to get most questions answered. But I like the idea of an “in-person” mentor who can help me discover things I don’t know I don’t know. Things about the general “art” of being a good developer that seems to encompass much more than just knowledge about what good code is like.
In my case, that would be Jonathan Blow and Casey Muratori.
It's not a mentor, but it can open up some options beyond books and stack overflow, especially if the projects you look at are full of comments.
Repeat few times. on 10th-time it might be much easier to change - and less error-prone - that on 1st.
Even easier done if the user is somebody else.
( if i tell u beforehand , that this, this and that should not be the way they are, or should be in some specific way, u may not believe me. "Who in hir right mind will ever use it like that?" ...well... maybe noone. Only when/if u hit/sit the nail on the sharp side, u find out which is what, for yourself )
have fun
COBOL ranters rarely make it to retirement age, 60/65.
Usually only intelligent, die hard, hardened professionals, make it there.
Find the real thing.
We have a mentorship program at my current employer, designed to alleviate the shortcomings where fresh grads post-COVID start their career working remotely and won't benefit from onsite interactions. The founder recognized the experience gained in those situations was crucial and the younglings just weren't receiving it. I'm mentoring two junior software devs currently.
I think mentorship is vastly underrated across society.
Programming is like learning the piano.
That's it.
Programmers need music teachers, and eventually professional self learning. Eventually you learn how to perform particular practice on your own.
The top tennis players, golfers, etc all have coaches. It doesn’t quite map to programming, but it shows no matter how good you are you can have something to learn from someone else.
Agree, though. The problem is there’s no way for anyone to know whether the knowledge being passed on by a particular senior to an apprenticed colleague is actually valuable. I see people pick up bad habits from their mentors as much as good ones.
There is a need to professionalize knowledge in this field. I have no idea how we should do it.