Unlearn, young programmer(blogs.tedneward.com)
blogs.tedneward.com
Unlearn, young programmer
http://blogs.tedneward.com/2012/03/21/Unlearn+Young+Programmer.aspx
14 comments
I worked in a near-ideal development culture once.
Thank you very much for this description. I find it gratifying and inspiring.
Everyone was quick to assume that if other people thought their code was confusing, then it probably was...There's unspoken machismo, which put into words would sound like this: "Nasty opaque codebase? What's wrong, can't take the complexity, little man?"
Also, I find this to be key. There is room for raw talent and huge, inspiring amounts of clever -- but it needs to be focused exactly where it does the most good. Let's just assume that one's competitors are in the same league when it comes to intellectual horsepower. Then it behooves one to make sure one's resources are focused where they do the most good. Let the competition dissipate their intellectual powers in developer pissing matches while you quietly outperform them.
Of late, I've come around to a radical stance on this. Modulo DRY, one should almost always target one's code to the lowest common denominator programmer on the team -- the newbie. This should probably follow an 80/20 or 90/10 rule. If a bog-standard well informed and competent programmer can't come in and start fixing 80% of your code within an hour, and it's not due to lack of non-programming specialized domain knowledge, then you're doing it wrong. There's room for elegant abstractions and the odd clever hack -- but you only get to have at most 7 of these in any given subsystem, and the code involved should be the minority of your codebase.
Clever is a valuable resource. Use it wisely.
Thank you very much for this description. I find it gratifying and inspiring.
Everyone was quick to assume that if other people thought their code was confusing, then it probably was...There's unspoken machismo, which put into words would sound like this: "Nasty opaque codebase? What's wrong, can't take the complexity, little man?"
Also, I find this to be key. There is room for raw talent and huge, inspiring amounts of clever -- but it needs to be focused exactly where it does the most good. Let's just assume that one's competitors are in the same league when it comes to intellectual horsepower. Then it behooves one to make sure one's resources are focused where they do the most good. Let the competition dissipate their intellectual powers in developer pissing matches while you quietly outperform them.
Of late, I've come around to a radical stance on this. Modulo DRY, one should almost always target one's code to the lowest common denominator programmer on the team -- the newbie. This should probably follow an 80/20 or 90/10 rule. If a bog-standard well informed and competent programmer can't come in and start fixing 80% of your code within an hour, and it's not due to lack of non-programming specialized domain knowledge, then you're doing it wrong. There's room for elegant abstractions and the odd clever hack -- but you only get to have at most 7 of these in any given subsystem, and the code involved should be the minority of your codebase.
Clever is a valuable resource. Use it wisely.
Then again, by being experienced, you know that certain things just don't work and never will. Until you see a newbie do them because he didn't know it was "impossible".
Like the guy presenting his NES emulator at jsconf.eu in 2010 which was practically a line-by-line port of a Java emulator. If you'd have ask me whether it was possible to line-by-line port a Java application (and a complicated one at that) to JS, I would have told you that, of course, this was entirely impossible.
Until that guy, totally new to JS and emulation -heck - even programming in general - just did it because he didn't know better.
Sometimes, having a new perspective is very helpful and we must be careful not to lose that. Sure. The solution might not be perfect, but one can always refine it.
Like the guy presenting his NES emulator at jsconf.eu in 2010 which was practically a line-by-line port of a Java emulator. If you'd have ask me whether it was possible to line-by-line port a Java application (and a complicated one at that) to JS, I would have told you that, of course, this was entirely impossible.
Until that guy, totally new to JS and emulation -heck - even programming in general - just did it because he didn't know better.
Sometimes, having a new perspective is very helpful and we must be careful not to lose that. Sure. The solution might not be perfect, but one can always refine it.
[deleted]
He implies that googling a problem will generally lead inexperienced developers to incorrect solutions. I think this is false.
He also assumes that Googling won't be the first thing junior developers do when they are given an unfamiliar task. Unfortunately, for too many, this is the case. The solution to that problem is to train junior developers to google. It sounds like the author of this article also has yet to learn the importance of googling first.
A lot of these problems are actually not new and are like the example of the picture. If you google 'how to hang a picture' you will find good explanations. You are unlikely to find a lot of people at the top of the search results who are telling you to cut the drywall.
When it comes down to SAX versus DOM, that's not really quite comparable to hanging a picture. In those types of cases, what you say to the junior developer is 'Google it and come back to me when you've found some example code that you are going to start with'. That way you can guide them if necessary before they get too far in. Or give them a starting direction, being as explicit as possible (point to code example).
If they are googling and coming back with really strange solutions (which, again, you tell them to go over the outline of the solution with you before they start implementing it), then maybe they don't have the intellectual capacity or experience for the tasks you are giving them.
On the second half of this post, he is also wrong. The timid and tentative developers will probably often get along fine with the more senior developers, because they are going to be happy to do things exactly the way they tell them and won't talk back. Part of the time they will be so clueless that they can't get anything done, and since they don't use Google they won't get anywhere but the others will be careful to follow the lead of the senior developers. So the traditional approaches will be passed on and everyone will be happy.
Anyway in the end he more or less gets to his conclusion which is reasonable enough, although stated in a way which I find to be somewhat arrogant. I think the entire basis for this was a fair amount of wasted time which was at least partly the fault of the more senior developer not providing initial guidance or checking in on the junior developer.
It IS definitely helpful when developers, whatever their experience level, are secure and modest enough to ask for other people's knowledge, opinions and help freely. I have found this to be rare. Too often asking questions is simply interpreted quite stupidly to mean that the other developer is ignorant. And also quite stupidly, not know literally everything is interpreted as ignorance.
To boil it down, the author sounds like a dick, should take some responsibility for the wasted development effort that he is trying to put all on the junior developer, should learn to Google himself, read my post, learn to ask questions himself, and work very hard at cloaking his arrogance when he speaks to the junior developer. And no I do not know who this person is and am not actually related to the situation. Article just pushes some of my buttons.
He also assumes that Googling won't be the first thing junior developers do when they are given an unfamiliar task. Unfortunately, for too many, this is the case. The solution to that problem is to train junior developers to google. It sounds like the author of this article also has yet to learn the importance of googling first.
A lot of these problems are actually not new and are like the example of the picture. If you google 'how to hang a picture' you will find good explanations. You are unlikely to find a lot of people at the top of the search results who are telling you to cut the drywall.
When it comes down to SAX versus DOM, that's not really quite comparable to hanging a picture. In those types of cases, what you say to the junior developer is 'Google it and come back to me when you've found some example code that you are going to start with'. That way you can guide them if necessary before they get too far in. Or give them a starting direction, being as explicit as possible (point to code example).
If they are googling and coming back with really strange solutions (which, again, you tell them to go over the outline of the solution with you before they start implementing it), then maybe they don't have the intellectual capacity or experience for the tasks you are giving them.
On the second half of this post, he is also wrong. The timid and tentative developers will probably often get along fine with the more senior developers, because they are going to be happy to do things exactly the way they tell them and won't talk back. Part of the time they will be so clueless that they can't get anything done, and since they don't use Google they won't get anywhere but the others will be careful to follow the lead of the senior developers. So the traditional approaches will be passed on and everyone will be happy.
Anyway in the end he more or less gets to his conclusion which is reasonable enough, although stated in a way which I find to be somewhat arrogant. I think the entire basis for this was a fair amount of wasted time which was at least partly the fault of the more senior developer not providing initial guidance or checking in on the junior developer.
It IS definitely helpful when developers, whatever their experience level, are secure and modest enough to ask for other people's knowledge, opinions and help freely. I have found this to be rare. Too often asking questions is simply interpreted quite stupidly to mean that the other developer is ignorant. And also quite stupidly, not know literally everything is interpreted as ignorance.
To boil it down, the author sounds like a dick, should take some responsibility for the wasted development effort that he is trying to put all on the junior developer, should learn to Google himself, read my post, learn to ask questions himself, and work very hard at cloaking his arrogance when he speaks to the junior developer. And no I do not know who this person is and am not actually related to the situation. Article just pushes some of my buttons.
You also get the other end of the spectrum, the "experienced" Lead/Manager who looks at hanging a picture and goes "These walls will never hold that" (when they've worked for years). Then he tears out the drywall and studs, gets the PM to read him the entire Building Code and agree to each line, puts in 4x4 posts instead of studs, all the while agreeing to re-tile the floor and paint the room, all on the same schedule as hanging the damn picture.
Any resemblance to anyone I've worked with is coincidental.
Any resemblance to anyone I've worked with is coincidental.
In short, to become a good developer, ask good questions, find a mentor, find opportunities to teach. Wise words for any profession I think.
I'm pretty sure any top student coming out of their course thinks they're a good developer already with all the right answers. To ensure they DO ask good questions I think providing mentoring for junior developers is probably one of the more effective investments you can make.
Agreed. As the above type of eager young developer, I can say it has been rather disappointing the lack of mentoring and direction at my first job. Junior programmers are just assigned to a task and expected to complete it. Programmers that don't ask questions and bug other more experienced developers don't survive. Developers like myself learn the ropes after a while, but it's frustrating to have no real direction or encouragement.
I know this probably comes off as the comments of a naive young programmer, but I sort of expected that companies would have some level of formal or informal training. I thought I might even be sent to attend developer events or conferences. At the very least I expected there might be some sort of formal internal forum for knowledge sharing, presentations, etc.
Because of (what feels like) a lack of skill advancement, I spend the majority of my free time playing around with technologies I feel like I should be learning at work. But at most companies there seems to be this "We're not paying your to learn" attitude. It's very disheartening coming from a university environment. Plus it seems kind of self-destructive in some cases; if a company as a whole falls behind its competitors technologically, how can it be effective as a business in the technology sector?
I suppose by posting this i'm just making an argument for why i'm a nailgun/drywall saw type of guy. Hopefully the transition to a working environment will only get easier.
I know this probably comes off as the comments of a naive young programmer, but I sort of expected that companies would have some level of formal or informal training. I thought I might even be sent to attend developer events or conferences. At the very least I expected there might be some sort of formal internal forum for knowledge sharing, presentations, etc.
Because of (what feels like) a lack of skill advancement, I spend the majority of my free time playing around with technologies I feel like I should be learning at work. But at most companies there seems to be this "We're not paying your to learn" attitude. It's very disheartening coming from a university environment. Plus it seems kind of self-destructive in some cases; if a company as a whole falls behind its competitors technologically, how can it be effective as a business in the technology sector?
I suppose by posting this i'm just making an argument for why i'm a nailgun/drywall saw type of guy. Hopefully the transition to a working environment will only get easier.
What you're describing is, unfortunately, standard practice in the industry - and has been for a long time. I've been around for a while and have been as frustrated by it as you. (Sorry for self-quoting, but I wrote about this in the last bit of http://news.ycombinator.com/item?id=3341058)
This may not be what you want to hear, but in my experience, organizations don't change much, so take your hopeful energy and channel it into finding (or starting) something else that is better. Hacker meetups and open-source projects are two ways to interact with other programmers. As far as work goes, try to find (or start) a place with a culture of collaboration. They're rare but do exist. The trouble is that absolutely everybody will say "yes" when asked if their culture values collaboration, mentorship, etc., and you need some way to cut through the bullshit. Best way I know is by knowing a person who works there.
This may not be what you want to hear, but in my experience, organizations don't change much, so take your hopeful energy and channel it into finding (or starting) something else that is better. Hacker meetups and open-source projects are two ways to interact with other programmers. As far as work goes, try to find (or start) a place with a culture of collaboration. They're rare but do exist. The trouble is that absolutely everybody will say "yes" when asked if their culture values collaboration, mentorship, etc., and you need some way to cut through the bullshit. Best way I know is by knowing a person who works there.
I lot of companies have real mentors. Ask about that before starting somewhere. Find out who your boss is. Ask them questions.
A lot of startups are bad at this because they're, well, starting up. I'm a big believer in mentoring, but a lot of startups I worked for didn't appreciate this at all. Just gotta keep looking.
A lot of startups are bad at this because they're, well, starting up. I'm a big believer in mentoring, but a lot of startups I worked for didn't appreciate this at all. Just gotta keep looking.
I think it's also important to point out that young programmers often don't know that what they don't know is reasonable to not know. As one of these drywall saw guys, sometimes I'm cutting drywall because I feel like I should be able to figure out a certain amount of things on my own. When I started my first (and current) job, no one ever expressed to me that it's okay to ask lots of questions and to not know much. Sure, it's probably the junior's responsibility to ask questions, but the senior has been in both situations. The junior has been in neither. The senior engineers have to have some responsibility for letting the juniors know to ask when they're unsure of something, etc.
Also, at risk being 'that guy' (also, proud suggester of using Rails in lieu of the GWT that every developer constantly complains about), I think it would be helpful for junior engineers to pair with someone more senior, at least some of the time so that they're not halfway through cutting up the wall before it's noticed. I know I've come up with some fairly terrible solutions now that I've learned better and I'm probably doing things now that I'll look at in a couple months and think are terrible.
Also, at risk being 'that guy' (also, proud suggester of using Rails in lieu of the GWT that every developer constantly complains about), I think it would be helpful for junior engineers to pair with someone more senior, at least some of the time so that they're not halfway through cutting up the wall before it's noticed. I know I've come up with some fairly terrible solutions now that I've learned better and I'm probably doing things now that I'll look at in a couple months and think are terrible.
I strongly agree with some of the interactions in this article.
Advice to Junior Programmers: Don't be 'that guy'. Don't be that guy that derails meeting and projects by trying to switch frameworks or languages or whatever. Writing code in your free time is different than writing code for a business on a team. Listen to your co-workers and go with the flow until you have a lot of experience under your belt.
Managers and Sr. Devs have a very keen awareness of when they run into 'that guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs want to be completing projects and not defending why they are using XYZ technology.
'That guy' has a good technical ability but no business sense and usually ends up being let go. This leads to 'that guy' thinking they have been let go because no one can see their talent and adopting a victim mentality.
Be a facilitator, not an irritator.
Advice to Junior Programmers: Don't be 'that guy'. Don't be that guy that derails meeting and projects by trying to switch frameworks or languages or whatever. Writing code in your free time is different than writing code for a business on a team. Listen to your co-workers and go with the flow until you have a lot of experience under your belt.
Managers and Sr. Devs have a very keen awareness of when they run into 'that guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs want to be completing projects and not defending why they are using XYZ technology.
'That guy' has a good technical ability but no business sense and usually ends up being let go. This leads to 'that guy' thinking they have been let go because no one can see their talent and adopting a victim mentality.
Be a facilitator, not an irritator.
'That guy' has a good technical ability but no business sense and usually ends up being let go.
I don't think so. 'That guy' usually gets lower raises and eventually wises up to his own annoyingness and then leaves for your competitor where he's no longer 'that guy'. Then you lose what would be a great employee because one time in a meeting he annoyed you. Treating toxic interactions with more toxic interaction just leads to a dead organization. (Mmmm, toxicity...)
There's a reason why we pay younger people less money than older people. They're expected to get things wrong because they don't have experience yet. Don't make up snide labels for these people; give them tasks that will give them experience. Mentor, don't judge.
I don't think so. 'That guy' usually gets lower raises and eventually wises up to his own annoyingness and then leaves for your competitor where he's no longer 'that guy'. Then you lose what would be a great employee because one time in a meeting he annoyed you. Treating toxic interactions with more toxic interaction just leads to a dead organization. (Mmmm, toxicity...)
There's a reason why we pay younger people less money than older people. They're expected to get things wrong because they don't have experience yet. Don't make up snide labels for these people; give them tasks that will give them experience. Mentor, don't judge.
"Writing code in your free time is different than writing code for a business on a team.... Managers and Sr. Devs have a very keen awareness of when they run into 'that guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs want to be completing projects and not defending why they are using XYZ technology.... 'That guy' has a good technical ability but no business sense and usually ends up being let go."
Sometimes 'that guy' is calling out the emperor has no clothes, and no one likes to hear that either. 'that guy' probably has business sense too, but perhaps not political savvy, which you're seeming to put above actual dollars and cents business sense.
'that guy' may in fact have come up with a way to get a 14 hour process down to 30 minutes, but it would offend people who spent 2 months building the 14 hour process. Or 'that guy' might suggest some technology that costs 20% of what's being paid now by using vendor Y, but then the manager who's getting some freebies from a friend for pushing the business to use vendor X instead of vendor Y.
No doubt, sometimes you get truly 'toxic' people. Sometimes you're getting people upsetting the apple cart, and the rest of the team is invested so much in the current apple cart that no amount of business-oriented justification will overcome NIH, and eventually 'that guy' will either get on board with 'the company line', or will leave, possibly to a competitor that's more open to continual improvement vs protecting the status quo from "that guy".
Sometimes 'that guy' is calling out the emperor has no clothes, and no one likes to hear that either. 'that guy' probably has business sense too, but perhaps not political savvy, which you're seeming to put above actual dollars and cents business sense.
'that guy' may in fact have come up with a way to get a 14 hour process down to 30 minutes, but it would offend people who spent 2 months building the 14 hour process. Or 'that guy' might suggest some technology that costs 20% of what's being paid now by using vendor Y, but then the manager who's getting some freebies from a friend for pushing the business to use vendor X instead of vendor Y.
No doubt, sometimes you get truly 'toxic' people. Sometimes you're getting people upsetting the apple cart, and the rest of the team is invested so much in the current apple cart that no amount of business-oriented justification will overcome NIH, and eventually 'that guy' will either get on board with 'the company line', or will leave, possibly to a competitor that's more open to continual improvement vs protecting the status quo from "that guy".
Actually this kinda makes sense. "That guy" usually preaches switching to what is latest buzzword. That doesn't lead to anywhere but if you have a person who consistently says "if we switch to whatever(whatever is a const variable here) our workload will be less", and if you don't listen to him and give a chance; you, sir, have made a huge mistake there. If you have that "that guy" in your business, give him a side project which will show whether his perspective is wrong. If not, and if that whatever is easy to learn, code and deploy... why not?
Sure, you should not, and honestly could not, switch frameworks and languages monthly but the coding field is not cast in stone, it evolves, continues to change and will continue to change (until we hit singularity and our a.i.s start to write code based on what we want).
Sure, you should not, and honestly could not, switch frameworks and languages monthly but the coding field is not cast in stone, it evolves, continues to change and will continue to change (until we hit singularity and our a.i.s start to write code based on what we want).
Be a facilitator, not an irritator.
Johnny Cochran called. He said he wanted his slogan back. Don't be 'that guy'.
For the record, I like getting things done too. That's exactly why I focus so much on having the right tool for the job at hand. And if it turns out that there's a better choice than the one that is being made, I will bring it to the attention of the people making the decision. Does it really matter in this situation who's more junior and who's more senior?
Johnny Cochran called. He said he wanted his slogan back. Don't be 'that guy'.
For the record, I like getting things done too. That's exactly why I focus so much on having the right tool for the job at hand. And if it turns out that there's a better choice than the one that is being made, I will bring it to the attention of the people making the decision. Does it really matter in this situation who's more junior and who's more senior?
So true. I've been "That guy", and it cost me my job. I didn't get it until then.
That guy here who was recently let go.
Thank you sir for your kind advice.But I think I will run my own business.It was my mistake that I thought I can co-exist with the likes of you.
Thank you sir for your kind advice.But I think I will run my own business.It was my mistake that I thought I can co-exist with the likes of you.
You'll eventually meet your very own version of "that guy". It is an inevitable cycle of life.
"In the face of ambiguity, refuse the temptation to guess."
this would be the best tl;dr for this article.
Just typed 'import this' on my python console to read the zen again.
Just typed 'import this' on my python console to read the zen again.
It's like the guy who wrote this article can see into my soul.
Most people on my team over the years we tend to be on the same page about projects, timelines, etc. But I've had people where it seemed like every minuscule detail had to be spelled out or the work wouldn't meet the requirements. That isn't just Jr. developers though, Sr. Developers can go the opposite way and spend months engineering and re-engineering without getting anything accomplished.
Basically I think it's easy to manage people who think similarly to how you think. It's a lot tricker managing people who have a totally different style or way of thinking.
Most people on my team over the years we tend to be on the same page about projects, timelines, etc. But I've had people where it seemed like every minuscule detail had to be spelled out or the work wouldn't meet the requirements. That isn't just Jr. developers though, Sr. Developers can go the opposite way and spend months engineering and re-engineering without getting anything accomplished.
Basically I think it's easy to manage people who think similarly to how you think. It's a lot tricker managing people who have a totally different style or way of thinking.
I feel this resonating quite strongly with me as I'm that young programmer that needs mentoring. Occasionally I get stuck with questions which I can't google answers for (for they result in the drywood type of solutions) and I don't have anyone to ask.
Sure, there are many, many people around me (professors, older students) who do know the answers to those questions, but but one question always paves way for another and asking them to make a commitment for longer than half an hour seems like asking too much.
An active open source project with an IRC channel might come a long way.
A very useful article. While the experience is drawn from the tech world, I think this is true for most professions. The bottom line is everyone starting out needs some guidance, and most of the time you are left to sink or swim. However, I think over time many, if not most (among those do make the effort to level up, not those who don't even try), eventually learn and get wise.
Right on target.
I see lots of these young programmers in every single project I work with.
Usually they tend to be hired by Fortune 500 companies (the customers my employer works for), as they are on salary level quite cheap.
But in the end their googling for solutions usually do more harm than good to the projects.
I see lots of these young programmers in every single project I work with.
Usually they tend to be hired by Fortune 500 companies (the customers my employer works for), as they are on salary level quite cheap.
But in the end their googling for solutions usually do more harm than good to the projects.
Ah, yes.
And of course, the young padawan who has built a rube-goldberg monstrosity that kinda works will be furious when you suggest simplifying.
And of course, the young padawan who has built a rube-goldberg monstrosity that kinda works will be furious when you suggest simplifying.
“But it would be such a waste to throw away all this code!”
Working on my own, it took me a long time to overcome this feeling. When you’re too stubborn or embarrassed or mad that you didn’t think of a better solution in the first place, it can be really hard to let it go. But nowadays, I feel better the more code I can remove.
Working on my own, it took me a long time to overcome this feeling. When you’re too stubborn or embarrassed or mad that you didn’t think of a better solution in the first place, it can be really hard to let it go. But nowadays, I feel better the more code I can remove.
So... how often will following this advice get you labelled as an 'idiot' who 'doesn't know how things are done' and really should be pawned off on some other company so we don't have to train this loser on company time?
I worked in a near-ideal development culture once. Twice, I suppose. Everybody was humble. Everybody documented their code. Everybody bounced their ideas off someone; even the smartest guy in the office humbly asked for advice and meant it. Everyone was quick to assume that if other people thought their code was confusing, then it probably was. Everyone assumed they should be able to explain their brilliant idea to anyone else on the team and convince them of its value. Most of what I knew about the codebase at those jobs I learned from guys who knew ten times as much as me drawing diagrams on the whiteboard and asking, "Do you think this will work? Or am I being stupid here?"
A junior programmer would naturally succeed at the picture-hanging problem in that environment because they'd approach it the same way the star programmers approached their work: tell other people what they're working on and what they're thinking, and make sure they can articulate and justify an idea before they commit themselves to it.
That's the ideal. Most cultures fall short of that in one way or another. In a completely opposite situation, if the star programmers work in isolation, disdain to discuss their work with lesser programmers, neglect to document their code, and aspire to write code that no one else understands, junior programmers will learn some very unhelpful lessons. This is true even if the star programmers are getting shit done and writing efficient, correctly functioning code, because they're basically (and I shudder to use this word because I don't want to start the wrong kind of conversation) peacocking. They're getting stuff done the hard way and proving they can thrive in a completely unsupportive environment. There's unspoken machismo, which put into words would sound like this: "Nasty opaque codebase? What's wrong, can't take the complexity, little man?" "Gosh, I would have written some comments if I knew some people needed them." That's the kind of environment where a programmer is going to either wilt and do something really stupid because they've already given up or "rise to the challenge" and try to make a drywall saw using a 3D printer.
Take care of the culture: set a good example, promote respect and humility among your developers, and don't exempt anyone from good practices. Then junior programmers will find their way even if you don't have time to guide them yourself.