Unlearn, young programmer
blogs.tedneward.com
blogs.tedneward.com
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.
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.
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.
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.
Any resemblance to anyone I've worked with is coincidental.
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.
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.
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.
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.
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.
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.
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".
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.
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?
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).
Just typed 'import this' on my python console to read the zen again.
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 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.
And of course, the young padawan who has built a rube-goldberg monstrosity that kinda works will be furious when you suggest simplifying.
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.