We Need Programming Mentors(paperless.blog)
paperless.blog
We Need Programming Mentors
https://paperless.blog/we-need-programming-mentors
45 comments
I aged out of my career (I left Corporate at age 57). My experiences though in my 50's were that the younger, new-hires were not much interested in apprenticeship or any mentoring I might have to offer.
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.
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.
Wow, thank-you for putting a description on that. I'll look out for the grizzled contrarians in that case.
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.
[1] https://anathem.fandom.com/wiki/Dialog
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.
[1] https://anathem.fandom.com/wiki/Dialog
> first 5--10 years of a developer's career for what they really are: an apprenticeship.
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 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.
> 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! 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.
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.
That's a good way to look at it, apprentices. Makes me think about the cover of "pragmatic programmer" which I should open again in fact.
Aged computer technician tries to solidify position and secure future ^
I don't think it's as much a question of age as it is of personality.
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 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.
What do you recommend instead?
I agree with the sentiment in the article, but there's so much demand on programmers' time that it feels the urgent often gets in the way of the important.
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.
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.
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).
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.
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.
> Comparing to the 90's is a complete strawman.
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.)?
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.)?
I have been considering offering just such a service but I haven't got the business experience to make the business work. I've done significant mentoring in all my recent roles and it's something I derive great satisfaction from. If I could spend most of my time working with mentees I would do it in a heartbeat.
There's codementor to do this. There really isn't much demand on the mentee side. It's mostly students paying for their home work to be done or adults with unrealistic expectations. There are far more mentors then mentees and each job is to competive to get, the hourly rates end up to low
> Programming is a new discipline.
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.
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.
> The following are entirely preventable mistakes from my own wandering career:
> 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?
> 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?
From those lines you quoted I don't see any reason to believe he's referring to dynamically typed languages. He's saying using an IDE on large code bases offers benefits like not having to waste time compiling in order to catch bugs
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.
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.
Dynamically typed languages can have strong type systems, ~~eg Haskell, some parts of Rust can be inferred.~~
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.
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.
> Dynamically typed languages can have strong type systems, eg Haskell, some parts of Rust can be inferred.
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.
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.
Haskell has a static type system. "Strictness" in PL theory usually refers to an eager evaluation strategy.
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.)
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.)
You are correct my comment did not make sense.
What I meant was that types may be inferred but that is not the same as dynamic typing.
What I meant was that types may be inferred but that is not the same as dynamic typing.
"Strictness" when applied to types usually refers to the existence of implicit type conversions.
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.
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.
> Haskell has a static type system. "Strictness" in PL theory usually refers to an eager evaluation strategy.
Ah yep. Meant static there and fumbled my words. That's what I get for browsing HN first thing in the morning before coffee.
Ah yep. Meant static there and fumbled my words. That's what I get for browsing HN first thing in the morning before coffee.
The point (when you take my comment in context) is that it doesn't matter if your editor does not detect typos, because the compiler will.
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.
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.
But using a basic text editor without even syntax highlighting, together with a separate compiler, extends your feedback loop on typos and syntax errors and - in strong type systems - logic errors your type system can catch.
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.
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.
On the other hand, autocomplete interferes with your thought process and makes you used to not having "long" programming thoughts: you can only think one word at a time.
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'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.
Anyone have recommendations for how to get a code mentor? Aside from people at work. I work for myself, by myself now.
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.
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.
The only way I know of to watch live programming streams from programmers your respect.
In my case, that would be Jonathan Blow and Casey Muratori.
In my case, that would be Jonathan Blow and Casey Muratori.
You might already be aware, but I wanted to mention it for anyone else who might be interested in software performance - Casey has a new “performance-aware programming” course [0] where he goes through how to write performant software. It’s a work-in-progress where he’s putting out a video (or a few) each week. It’s pretty great so far. For anyone who’s done a CS degree it seems reminiscent of the architecture class where they taught about the CPU and assembly, except this is covering modern CPUs and SIMD and stuff, and focused on writing for maximum performance.
0: https://computerenhance.com
0: https://computerenhance.com
Agree with this. I learned a lot from https://www.youtube.com/@JonGjengset last year even though his video is so long.
One avenue that people tend to ignore is to look under the hood of code you already use. I've learned an immense amount from looking at the source code of open source packages I use, and seeing how the internal code is structured, what tradeoffs they make, etc.
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.
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.
here an idea. invent some low-UI personal project, e.g. with Command Line interface. Sorting mp3s, whatever. Think well what u might need as functionality, say 10-15 items, not more, put them as options of the CLI. Code it fast - don't overthink it. Leave it as such and use it for a while, like it's somebody else's closed-code. Everytime u find out some extra need or non-fatal-mistake, fight the urge to fix it, note these down. When collected enough of those (how much is enough? 10? 5? 2? maybe when it gets to your nerves), refactor it, with further/modified vision of what u need. (and now, how u need it coded).
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
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
Learn from some of the best. For example read and do the exercises of SICP followed by "Software Design for Flexibility - How to avoid programming yourself into a Corner". The authors have more than 50y of experience and go through multiple iterations and refactorings of examples, pointing out good and bad aspects of the code.
I have submitted PRs to Github repos that had proper, strict code review in place. That was as closest I've gotten to code mentoring
https://exercism.org/ is a nice place to start.
I don't know... it might be a nice start to test some coding skills but the level is a bit off. Something like 'create a ring buffer' is rated as 'hard'...
Find retired programmers. Buy them coffee.
But I can already read unending COBOL rants online?
All jokes aside.
COBOL ranters rarely make it to retirement age, 60/65.
Usually only intelligent, die hard, hardened professionals, make it there.
Find the real thing.
COBOL ranters rarely make it to retirement age, 60/65.
Usually only intelligent, die hard, hardened professionals, make it there.
Find the real thing.
I'm mentoring my wife in her journey from Salesforce user to admin to architect. She gets stuck in Trailhead with new software engineering concepts and I am there to help explain.
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.
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.
"Mentor" seems too complicated.
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.
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.
In some sense yes. However, everyone at any level benefits from a teacher/mentor/coach, if only to get some outside perspective.
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.
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.
[deleted]
That’s more a description of ‘apprenticeship’ than ‘mentorship’.
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.
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.
This was posted yesterday?
https://news.ycombinator.com/item?id=34738680
https://news.ycombinator.com/item?id=34738680
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.