I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school.
But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enough if you follow it with a "but".
"Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work"
will get better results then this
"Hey pretty cool program, but you're reading in files wrong"
which even that is better than this
"You're reading in files completely wrong, try googling for a better solution" which unfortunately among engineers seems to be the most common reply.
I like teaching. I don't think I'm amazing at it, but I like sharing knowledge and experience with my friends and co-workers and see them improve, or just sometimes for the abstract sense of helping. Of course, sometimes I fall flat and come across as arrogant or condescending, but I hope that's rare. I read "How to make friends" a long time ago, and I apply those rules diligently to my interactions with people.
Recently though, I've been assigned a guy to help me with one of my tasks, managing the build pipeline. This requires a wide range of knowledge about unix and scripting (Bash, Perl AND Python. Yup. On top of Makefiles, of course).
The guy doesn't know how to use a command-line.
I'm surprised to find myself to be very unhelpful and curt with this guy. He's the unlucky recipient of my resentment at the amount of effort I will have to put in before he can actually become remotely helpful. Of course, it doesn't help that he's in far off timezone where I'd have to stay up late to help him, and that I have trouble getting direct answers from him about his knowledge level. The communication and experience gap is too large.
Anyhow, this is just my two cents relating an experience to show how a seemingly normal and friendly human being can revert to angry "RTFM"s.
Very well said. It's wrong to be a dick, but it's also the natural response to a lot of stressful situations. Think of trying to give tech support to relatives, for example. It's too easy to get annoyed with other people, and this is especially true when you're under pressure and they're MEANT TO BE HELPING, DAMNIT!
FWIW, I suspect that you're much more experienced in this stuff than me, so it's a bit arrogant for me to offer a suggestion. But still, I'm going to offer one. Is the guy quite self-motivated? If so, one thing that might help you is to spend some time curating good learning resources for him, and then linking him to them. It's essentially the ethical version of RTFM. You help him figure out what the useful "M" actually is, and he'll get himself up to scratch from there.
That's actually the route I've been trying to follow, but that's where the experience gap becomes a problem. I can give him some ressources on how to use Git or learn Python, but it's been so long that I don't even know where to start for the CLI :|
I had the same problem with a past coworker, a "how is this person being paid to work with technology in any capacity" person doing development and having never learned how to read graphs ("the CPU is at the top of the graph, so that is the cause of the performance problem" was common). Or knowing that Excel could do visualizations of data. And I found myself doing the "Blatantly type their question into google right in front of them and click on the first link" thing and being super short and RTFM-y which made me feel bad afterward. But so resentful.
I had an IT job where I was the only person taking care of all office technology for 22 locations. This got bigger over time and I pushed management to get me some help. I got some halftime assistants, one of which was great, but he was a young guy and decided to move on after about 2 years (I was rather pleased this was the longest he had ever held a job!)
Then the powers that be decided I needed a manager, and hired some old wreck retired from IBM. I have no idea why. Old? Male? Wore a suit and would be more presentable to the board than me (not hard)? It was certainly not for his knowledge. He couldn't fix a PC, diagnose Windows problems, or use a Unix command line, and actually added to my workload because he would break his computer and need me to fix it. A co-worker quietly told me he spent his day playing Solitaire and taking messages because he was unable to solve problems.
He didn't seem to want to learn, either. That was the kicker. I would usually spend an hour a day teaching my previous assistant about networks or software, but this guy, his ignorance was just too big and he just didn't express any curiosity. I'm pretty sure his job was to collect a paycheck.
I quit. There wasn't really much choice. I was overworked and insulted. And within 2 weeks he resigned as well.
> Anyhow, this is just my two cents relating an experience to show how a seemingly normal and friendly human being can revert to angry "RTFM"s.
The guy is not just a human being, he's also a professional whose job it is to know what he's doing. Shouldn't there be some sense of "duty to do a job well", not just "duty to care about someone's feelings"? If he's not pulling his weight and is failing at his job, then the poor responses are his fault also.
Sound like you haven't been working with outsourced talent and a boss that says "this is all we've got, deal with it." ;)
The "interesting" thing here is the cultural gap, where these folks have had all initiative beaten out of them throughout their education, where the cost of failure is higher than that of not trying. It's really disheartening.
My point is, it's heard to blame the person when you know how flawed is the system they come from.
> Anyhow, this is just my two cents relating an experience to show how a seemingly normal and friendly human being can revert to angry "RTFM"s.
Sure. We're all human, and I know I've been there many times. Just also remember how the seemingly normal and ready to learn human will react to a lesson put that way.
"Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work"
I usually hear this referred to as a "criticism sandwich": Criticism surrounded on either side with compliments.
We Brits are the masters of allusive and indirect speech, and I would automatically automatically strip of both pieces of bread translate that to "you're reading in files wrong".
Yes, I would automatically parse the "bread" as being boilerplate politeness -- but as with most forms of politeness, I would probably feel differently about the speaker if it wasn't there.
I think you have to take each individual differently. Most folks react well to the criticism sandwich. Someone like you might prefer a more direct approach, as long as it is not phrased in a mean way.
At some point in my career, I stopped taking criticism personally. I just realized I was wrong so often that upholding the pretense that I knew it all was too hard. For that reason, I prefer direct suggestions.
If I was teaching a child or a new beginner, I would start with a lot of praise that they're even trying. I want to get them some early wins to help boost their confidence.
What's weird is that even though I know this is a "trick" I still want people to talk to me that way unless I specifically ask them for the hard truth.
Programmers tend to incline towards efficiency. I think that's why we often skip the bread and deliver only the filling. IMO there's a big difference between a criticism sandwich and tactful criticism.
Delivering constructive criticism in a polite and non-abrasive way is more efficient. If abruptly telling someone their wrong causes them to take offense to the help you're trying to provide, they'll likely disregard what you've just told them out of pride or spite and you'll reduce their willingness to work with you on future problems.
By being polite you're ensuring that the message you're sending gets incorporated into their strategy for tackling that problem and making them feel comfortable discussing other issues with you.
As programmers, we have to learn that 'programming' people is very different from programming computers.
Efficiency is one thing, being a douche is another. Programmers are still human beings and while they might tolerate some harsher comments, they still affect them. Efficiency yes, but not above all.
on the other hand, would you like to work with someone that doesn't take criticism well and whom jumps on the defensive about random pieces of code, of all things?
I think the key is to give an honest compliment on not a bullshit one. So instead of "great job on the thing! but ..." maybe "great job finding and diagnosing the root cause of that problem, that was pretty hairy, but I think there's a better way to fix the root cause".
Don't you feel patronized when people do that though? Be as rude as you want to me, as long as you're correct.
As for myself, I tend to not call out the positive parts of something, because that's sort of implicit. I would not bother to point out that the file reading code is wrong if the whole thing was broken.
I admit I'm probably incorrect here, but I notice people try this "say something positive" and it really comes off wrong. Or maybe I don't notice when they do it well.
I strongly agree. Sentence formulas are a hack. The actual advice should be, believe something positive. Specifically, believe that the person is basically smart but just didn't know X. That leads to natural utterances like:
"Sweet! Uh...that run time is pretty terrible though. Don't worry, let's see what's up with that. (Twenty seconds later:) Ohhhhhhhhh, ha, ok, check this out."
The novice coder knows they suck. They're not really worried about that because, well, they're still here. What they are worried about is that you'll write them off. So don't.
I think it just comes down to different personalities. I'm just like you. I tend to get agitated when people try to sandwich their criticisms or compliment me for irrelevant things when I just want them to get to the point. I'd very much prefer someone just telling me "your code is shitty and here is how you'd fix it and why." Unfortunately, people that take criticisms like us seem to be in the minority.
That's why I personally declare Crocker's rules[0] - if you want to tell me something, I allow you to skip pleasantries and "social hacks", and just get straight to the point.
The trouble is: that's not how humans work. Including ones who push Crocker's rule. Personalising negative comments is how human brains work.
Remember: knowing a bias exists doesn't make it go away, at all.
In my experience, the sort of person who professes a love of unvarnished communication is someone heavily into sending it - the same people reliably hit the roof whenever they receive it.
Public relations is 50% of the job, even if you're bad at public relations. There are no quick hacks to make that go away, 'cos if there were then everyone would already be using them.
I gotta wonder, do you actually have such confidence yourself that you assume that everything other people _does not_ comment was good? If so congratulations! A suggestion though, on how you could improve the confidence in people like me - who aren't sure everything not mentioned is good - would be to actually point out the positive parts even if you don't feel that it is necessary.
I have to admit though, it took many years and a few courses in psychology until I finally could admit to myself and my surroundings that I actually need positive reinforcement, that negative reinforcement, even if true and relevant, could even be detrimental to my performance.
I do agree on the importance of not just "say something positive", it has to be real, most people have probably filled their quota of obviously false/exaggerated complements in preschool. I myself struggle with finding the right balance between sounding patronizing and being overly critical.
I suppose there's a difference between when you're working with someone versus showing off to other people. If I'm doing a Show HN or I email a friend to check something out, sure I love flattery and compliments as anyone. It's within the technical scope of working together that I find it obnoxious.
And it's not really self confidence[1]. It's more of an extension of principles of coding. Anyone can write a system that does X. But doing X when things go well, and doing it in the face of errors, edge cases, and other faults - that's what it's all about. For me, anyways, when I'm writing code "as an engineer". So I don't find it particularly notable that something works. Of course it " works ", or you wouldn't be telling or showing me in the first place! Likewise if I ask for a review and your only comment is " file buffer is too small " I'm gonna guess the rest is alright else you wouldn't bother pointing out smaller things. If I'm unsure about something, I'll ask about it explicitly.
Outside of a feedback system like a code review, it is important to let people know you appreciate their work. And it's to my detriment that I don't let people know, honestly, when I appreciate them. But that's separate from mixing it in with criticism.
1: I've low confidence in my self confidence. On one hand I know I have a fairly good error rate and I'm objectively better than a lot of other developers. Yet, especially here on HN, I can plainly see I'm nothing special. But this doesn't really assure me that any particular piece of my work is good.
> I gotta wonder, do you actually have such confidence yourself that you assume that everything other people _does not_ comment was good? If so congratulations! A suggestion though, on how you could improve the confidence in people like me - who aren't sure everything not mentioned is good - would be to actually point out the positive parts even if you don't feel that it is necessary.
If you learn another language (a human language), and try to practice it with native speakers, you'll quickly notice that they never comment on your correct grammar. (It's not exactly common for people to comment on incorrect grammar either, but it can happen.) The only way to learn that your phrasing was correct is to ask outright, or observe someone producing an exact analogue of your sentence. This is a source of great aggravation to me, but things couldn't reasonably be any other way -- most of the correct stuff people say is stuff that they already knew was correct.
I agree... to a point. It reminds me a bit about this quote by Ricky Grevais:
"The other thing about it is:
Comedy comes from a good or a bad place.
And I think that the funniest people always
comes from a good place. Two people can say
the same thing, and one person can be so
nasty and vitriolic -- and therefore not funny.
And the other can be, you know, a celebration.
You know, you can be in on the joke."
Corny as it might sound -- I think brutal honesty is more constructive when it comes from a place of love. I'm not sure what the practical take-away from that is. Maybe build trust first, and then be direct? Or be honest, but avoid being mean?
OTOH I think everyone deserves/needs a good bit of BOFH bootcamp to slap them into reality before they are let lose writing code that talks to the Internet... ;-)
This is helpful for sure, but it's also very useful to work on having a thick enough skin to take insulting feedback in a positive fashion. After all, the only way someone can offend you is if you let them.
You've offered a compliment, then suggestion, then a platitude, while telling someone that being rude is acceptable if it's technically correct and seemingly disagreeing with the previous poster.
It's sound advice, to have thick skin, but you've just shown how easy it is to give corrective feedback in a tactful way. Still good advice to not let people offend you though.
I'm a junior dev, I have a ton to learn and I don't for a moment think I know more than our senior dev. But working with this guy, and trying to learn from him, is a nightmare.
When I ask "why should I do this rather than that?", I either get a muddy explanation, or none at all.
Worse still is inconsistency. Just recently I was working on a project, went through several reviews without comment on the approach, was told "almost done just fix these tests". After waiting a week for review of those last tweaks, the review was "this is fundamentally flawed and shouldn't be done this way at all."
Now I'm not saying that's wrong, but it would have been better to hear that three weeks ago. Nor is the explanation of _why_ it's flawed the slightest bit clear.
Further, the new approach does _not_ support the business need motivating these changes in the first place. I am figuring out how to support that need within the directed approach, but it is harder than the first design would have been. Again, that doesn't mean I was right -- sometimes there are choices where you put the ugly stuff. These changes are pretty deep in our architecture, and so touch a lot of code. If being clean there means that some top-level stuff is more complicated, that is probably the right trade-off. But it would be nice to have a "sorry, I didn't think this through soon enough." And no, I am not the idiot I'm made out to be because I didn't, as a junior dev, immediately and fully understand how all the pieces should fit together.
Nor is this a two-way street. I've had moments where I've pointed out what seems like problems, been told I'm wrong, or ignored . . . and then find that the issue is quietly fixed a few days later. We do some stuff that is just flat wrong because that's how he likes it.
I'm not the only one, the others with more experience than I have similar problems.
I'm learning. The guy has good instincts, so his critiques usually lead in the right direction, so I roll with it and figure out the principles for myself. But it is absolutely zero fun working with this guy. I've become averse to submitting code for review, because I never know when the process will take 180 and stuff that was fine becomes crap. And while I think I'm getting better, I have to figure out how to build confidence in those skills, because I'm not going to get it from this feedback loop. Probably that will be working on my own projects, taking what I'm learning and using that to make them better. And at some point I'll move on.
Tough feedback, even insulting feedback, is ok with me. I'll work with it. But if you're going to be tough, then you have to be fair, you have to be clear, and you have to be right.
I usually ask more senior people why they say that, and keep asking why until I get it. If this process seems to be going on too long, I ask if there's a book or reference I should be reading to understand the subject better. Honestly, most senior people will be very pleased that you care enough to find out why, including following up with external resources.
If a senior person won't explain something if you ask politely, usually either they don't understand it themselves, or they are simply not very good at explaining things. Not all senior people are good teachers. It sounds like your team lead is one of the latter.
The problem here, and you'll encounter it with clients and seniors throughout your career, is that your senior/boss doesn't have enough time, or thinks they don't have enough time, to supervise your work correctly and thus comes in at the last minute and drops hidden requirements/fundamental changes on you. It's very common.
If you want to avoid this, you're going to have to make it your job to point out potential flaws and hurdles in your work as you come across them, to ask only for essential and broad-strokes guidance up front, and to find/fix smaller issues yourself as you go along without bothering the higher ups. Your senior probably genuinely wasn't aware of the deeper issues with your work because they just didn't have time to do anything but scan your code and hope for the best, because their senior is hassling them about a,b,c, which are far more important.
Now that was flawed on their part, and they're doing their job wrong, but you can help them fix that process, if you want to, and it is a good skill to learn. You absolutely should not be avoiding code review, you should be guiding that process in a direction that is in everyone's interest. The world of work is not remotely fair, clear or right - it is very rarely even one of those, but you can make it better yourself by managing upwards and making your requirements and concerns clear at a very early stage.
In my opinion the dichotomy of tough but fair/nice but inaccurate feedback is a false one. Most feedback is rushed, muddled, partly correct, partly irrelevant, partly insightful and still useful if you know how to mine it.
I'm an engineer, and I've gotten so much benefit out of that book. I read it cover to cover several times a year. It's very corny, but it reminds me of several things I often don't conciously think about when interacting with people. Sometimes reading that book is the only way I can get through the day and interact pleasantly with people.
One reason engineers can be unintentionally critical is that their job is often "find what's wrong with this thing and make it better". It's rarely "find what's right with this thing and congratulate someone". It takes me quite a bit of mental effort to switch from nitpick mode to encouragement mode. I've tried to consciously balance my criticisms by leaving a few honest encouraging comments in code reviews like: "thanks for improving test coverage here", or "glad you handled timeouts and retrys, this api has given us grief before".
> "You're reading in files completely wrong, try googling for a better solution" which unfortunately among engineers seems to be the most common reply.
I can empathize with this because I feel like saying this all too often. I guess it's a mentality of "teach a man how to fish". I guess I could use a reading of "How to Win Friends & Influence People".
The problem with the "win friends and influence people" method is that some people just listen to the positive parts and go right on their way never improving.
We aren't selling cars nor running for office where "win friends" is particularly useful.
I'm also not saying we should be deliberately nasty or personally demeaning. But we shouldn't let shit pass just to be nice either. There is far too much of that nonsense in the world, and the net effect of it is a theft from everyone.
We should try to be our best. We should ask others to be their best. We should always be positive and helpful and teach others what we can. But we should also be direct when something is wrong and we know better. This in the best interest of the person, the project and the organization. The ability to give and to accept honest criticism with the goal of improvement is unfortunately strikingly rare.
When we don't know better we should keep our mouths shut rather than bluffing and blustering our way along. If I had 10 bucks for every loudmouth know-nothing trying to impress everyone or score political points I have met in life I'd be rich. The tech scene is particularly full of these kind of blowhards in my experience. Some people have a hard time telling the difference between positive honest criticism and ego driving showing off. And some people just plain don't know what they are talking about but talk anyway. This kind particularly needs to be called out in the most direct manner possible for the best interest of everyone involved.
When I read that book by Dale Carnegie one think struck me. Aside from being well with words and advice he never succeeded in his own life. Two divorces and almost no friends at the end of his life.
General advice is easy to give. There are millions of tiny details which tend to guide you away.
But (yes, I buted), I think a lot of people go overboard. I've seen people get so bent up around coming off as nice and encouraging, that it becomes difficult to even understand what they want from you. Or worse, it comes off passive aggressive.
I'm not sure there's a better fix for that than practice.
Hah, nice to hear that famous book (which I've never read so far) coincides with my understanding and behavior. The only motivation for me is that I value people and their feelings much more than any other thing. To be honest, it is not planned or contrived... It is just a natural feedback.
What's interesting is that XKCD shows replies that are even worse than your last reply- even suggesting Googling provides a course of action. XKCD's more like "My grandmother could read files faster than that."
If only my clients and recent bosses would consider refactoring a valid billing line item...
I can only imagine sending an invoice today to my three top clients with "5 Hours Refactoring Bad Code That is Working But Could Be Better Looking....$400".
There is just no way I would get paid.
Unfortunately, I have interests outside of working on code that mostly preclude me from sitting for hours happily breaking-and-then-refixing code that is currently working ok and that I cannot bill on.
Hell, just keeping up to date with the unreal pace of change that is occurring in software right now is almost a full-time job in itself, much less fixing old stuff that is going to go away soon anyway.
Solution A is obviously to educate them: $400 as time spent to make adding the next 10 features cheaper.
Solution B is to refactor some fraction of the code you interface with when adding a new feature.
So it's "X+2 hours adding new feature" when you spent 2 hours refactoring code that feature X needed to deal with.
As far as the ethics of Solution B, then if your refactoring is actually improving your net productivity, then you truely are doing necessary work towards adding the feature (just as you would bill tests or build scripts needed for the feature along with it). If it isn't improving your net productivity, then why are you doing it?
How about "I did my job, and if you ask me to specify how much time I spent on testing and refactoring, you're a micromanager and you're redundant because you obviously have nothing better to do"? As a developer, you need to take your own responsibility for the code and product you create, and be proud of it. Besides, it's a fallacy that time not spent on code quality would lead to more features / a better product.
> So I wrote a Perl script that read in the file, combined it, and printed it out as a single line. Then I had my Java program call the Perl script through the command line, capture the printed output, and save that as the string.
When I first started (in Python), I didn't understand what a function was, but I wanted my program to react differently depending on user input, and had some conception that I should be breaking my program up into files by purpose. So what I did to get it working was this: I named each file "$cmd.py", then I concatted the user's input with ".py", opened & read the file with the associated name, and ran the resulting string through exec() !!
I came to this result incrementally by googling different aspects of the problem that I didn't know how to describe properly. If someone had been a jerk to me about it then, I probably would've been really self-conscious about it. But no one was a jerk, so I'm not ashamed: what I did is ridiculous and funny & I'm glad to be able to laugh about it now.
I agree that mean-spirited feedback is not helpful/constructive. I can see how that would discourage someone who is new to programming. In fact, "feedback" is probably not even the correct name for that... maybe "bullying".
However, I have to disagree with the notion of having to write a lot of shitty code to learn to write good code. Granted, that is one way to learn, but not nearly the most effective way to learn.
For years, when I started my career, I wrote lots of shitty code. I feel badly about having done this because I unwittingly caused quite a bit of havoc in the products I was working on, and even pissed off a few customers along the way. Writing shitty code can have really bad effects on a team and on a product.
Fortunately for me, I eventually ended up working in an extremely talented team. They were not only talented at programming, but also highly skilled at teaching others good programming. Their method was simple- they accepted nothing that failed to meet their high (and documented) standards of readability and testing, but were extremely thorough in spending time showing you what you did wrong. They were never demeaning and always constructive- they always had a high level optimism in every new-comer's potential. Given enough time, it was clear that some new team members weren't going to work out, but those who had it in them to patiently improve their skills flourished and enjoyed very successful stints with this team.
After a rough first few days on the team, I heeded their warnings and agreed to check my misplaced ego at the door. Then, and after a couple of months of embarrassing ineffectiveness, I gradually became a better programmer and went on to become a great team member. I'm really grateful for the patience these guys had with me and the other noobs. They really made a difference in my career and in the career of my peers!
This kind of thing can really have an effect on your career in the immediate future. There are a lot of expectations that people come up with regarding what you should know by X years into your career and people judge you pretty strongly on this.
I personally don't get any feedback on my code and I don't really have time to police myself on it. I end up blending in with the conventions I see in whatever current document I'm working on (e.g. presence of type prefixes, casing style, underscore usage). I always thought this was bad practice in the general population but I guess I get paid for it.
We aren't going to raise the industry-wide skill level if we let people figure it out on their own the hard way. That's valuable up until a point but eventually they should start wanting to know what the effective way of doing X is (if it exists). Individuals take a long time to arrive at an optimal point with that stuff, and may never even reach it.
I'm fairly sure NASA doesn't let staff (astronauts especially) in training learn everything the hard way. Imagine if your workplace maintained something like this: http://llis.nasa.gov/
Not quite right. All the code I wrote last year looks bad to me; naieve, clumsy, artless. Because I have learned so much since then. It never gets any better. Not because I don't get better; because I DO get better.
I hear this sentiment a lot (and notice it in myself, though I have a lot less experience so it hasn't been as long running), and it worries me.
Are you sure it's better? Are you keenly aware that there are no, say, cycles in your coding approach?
I know this year I look back at last year's code and go, "oh boy, why'd I do it that way?" And I feel like it's better, but I'm always a little afraid I'm just chasing novelty. Not sure how to objectively know if it's better.
Don't forget also that familiarity makes things seem more clear. Code you wrote yesterday needs to be particularly atrocious for you to find it hard to understand. Code you wrote a year or two ago might as well have been written by a stranger (really memorable hacks aside).
Perhaps look at code from 2 years ago and 3 years ago, and if possible blind yourself as to which is older, and rate each one.
I'm pretty sure I remember my code. I agonize over it, put all my effort into it. I remember code I wrote in the '80. I remember the code I wrote 7 years ago, and refactored last year. Code is my life.
I've had that sneaking suspicion that maybe I'm not really getting any better, yes. But I have independent corroboration - I've worked with another guy for most of that time, and we've got one anothers' code to look at. What one of us learns, the other learns too. He's not cycling, or just writing bad code. And he says the same about me.
I'd say about half my bad code is due to inexperience, what the post is referring to. As time goes on it DOES get better, especially since -- like most of you -- I'm constantly reading and trying to improve my skills.
The other half of my bad code is due to time constraint. This is either because a quick hack is needed, or the proper planning time is not allocated to do a proper job.
This leads me back to my initial statement. Sometimes you just need to get the job done. If you're not good enough to do it right, but you hack it and it works, that's good enough for now.
This is how systems get built poorly and bloat up, but there are deadlines and requirements that need to be met, and if you never ship, you'll never get the budget to rebuild that old system you allowed to get unwieldy. It's a constant struggle to balance quality, functionality, and deadlines.
There are some useful ideas here, and public shaming per se probably isn't the answer. But publicly talking about bad code, and the properties of code that makes it bad, is an important way to socialize what makes good code, plus the meta fact that code quality is important.
To the extent that the aphorism about writing bad code is true, I think it's just another way of saying that people's code improves with their coding experience. I really don't think you need to write bad code _in order_ to learn to write good code. It's hard to know for sure, but I think the most positive influence on my code quality was _reading_ lots of very good code, not having written bad code. (It's the same with my writing, too.)
I think this is reasonable, but at the same time, please get those million lines out of your system on somebody else's project.
If that can't be done, if you can't spend your free time honing your abilities, then accept helpful feedback from other more experienced developers. Don't just accept feedback--assume your code is garbage, and ask how you can make it better. If the answer eventually becomes "it's good enough for business purposes", then find out why that is, and learn from that.
Communication is hard, and explaining why a codebase is just wrong can be as difficult as explaining to somebody why you find them abrasive.
At the same time, it's the job of senior engineers to make the effort and try.
Sadly, in a startup environment, it's usually smarter business-wise in the short-term just to sack the inexperienced developers or railroad them into simpler work that they can't screw up, and kick the can down the line.
I'm not a real fan of assigning a context-independent global value label like "good" or "bad" to code. While there probably are examples of truly "bad in all respects, in any context" code, the vast majority of code that I've seen tends to fit more into "<this attribute> of the code could/should probably be improved when using it in <this context>".
I find that viewing (and discussing) code this way has a lot of benefits:
* It is really hard for a single global negative value judgement made about code to not be taken personally by the person who wrote it (e.g., "your code sucks" == "you suck"). This is much easier to avoid when talking about attributes of a thing, since (a) it comes across as more objective than subjective, (b) gives plenty of opportunities for acknowledging aspects of the code that _don't_ suck, and (c) lends itself to much more of a "give and take" discussion.
* It gives you the opportunity to talk about "figures of merit" and trade-offs that are the reality of engineering, but rarely taught in schools (e.g., readability/development cost/flexibility vs. performance, etc.)
* It gives you a framework for explaining why things like idiomatic style, "principle of least astonishment", and general elegance actually contribute to code quality (and aren't just excuses for subjective attacks).
I don't see anything wrong with the "mean-spirited" humor in the XKCD comic. The cartoon is funny. It's supposed to be a joke. Anyways, it's not like those remarks are directed at anyone in particular -- just a fictional stick figure. I don't have any ethical qualms about laughing at his expense.
You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-)
That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it.
In fact, I'm almost always very impressed with people who are not professional coders but who have taught themselves a few coding skills in order to solve some problem or to actualize some idea -- even if the code itself is horrific from a professional standpoint. That's awesome! And if they want help, I won't mock -- I'll help! It's a rare opportunity to really show someone why I find the act of programming to be so fascinating and satisfying.
> You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-)
Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code.
Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without errors" lol
> That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it.
I understand that you feel passionately about this, and I agree wholeheartedly that non professionals should not be mocked. That said, I dont think that's what's going on here. What we have here, is a cartoon that's poking fun at an exaggerated circumstance. No individual or group is being (sincerely) called out or told they shouln't try to learn to code. It's all just a joke, for amusement.
Its like saying Peanuts is mean spirited for mocking people with poor hygiene with the character Pig Pen: It discourages those people from leaving their homes and interacting with people. I should instead encourage those with poor hygiene to pick up that bar of soap and go outside!
> Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code. Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without errors" lol
I'm just poking a little fun at your earlier reductionism. You're right, it's just a stick figure. A real human has not been hurt.
My main issue with the comic is that it's not particularly funny. To me. The zingers don't really zing. It's just someone whaling on someone else for three panels. And since I'm not catching onto the humor, all I'm left with is the weird feeling that the comic is condoning that kind of behavior.
You're overthinking a cartoon in attempt to find malice where there is none. I'm sorry you didnt find it funny, but that doesn't mean it was written to be anything else but humorous.
There's nothing sinister in this cartoon, no matter what you feel. You might as well accuse all cartoonists of condoning their characters' outlandish behaviors. (e.g. "The writers of the Simpsons must condone child abuse because I didn't find the humor in Homer choking his son" ... Give me a break.)
The cartoon was clearly meant to be humorous. The humor fell flat. So the cartoon just comes off as mean. It's not the end of the world. I'm not going to attempt to reconcile it with Pig Pen and Homer Simpson in some effort to create Chasing's Grand Unified Theory of What Is and Is Not Mean-Spirited.
I kept some of my original bad C, asm, and REXX code back from my high school days after I finally moved on from BASIC in 1991. I pull it out from time to time for a quick chuckle.
You have to have thick skin in the programming industry. Because you're surrounded by what might be the world's worst communicators, programmers. We can tell the machine exactly what to do, but our social IQs tend to suffer on the whole.
Not to mention we're told from a very early age how smart we are so inevitably we begin to not only believe it but also believe we're smarter than everyone else.
Here's a hard-earned lesson for any newly-minted developers out there: Yeah, you're smart. But not as smart as you think you are. And regardless, it doesn't give you license to treat anyone poorly.
I have here some 10 year old C++ code I've written lying around. It's pretty terrible style-wise, but not as bad as I imagine it to be without looking at it.
But the main point is that it worked in production for years. I would have written it much better today, and it will probably work faster and be easier to maintain. But it would also probably take longer to develop (though less time to debug and stabilize) - and ultimately, it would do the same work in production.
I'm not saying that improving your coding style and skills is not important. Just that we need to keep our eye on the ball - which is delivering working software, not code.
There's a difference between practice and mere repetition. You wouldn't get any better at speaking Russian if you just spoke gibberish, even if you did it for 10 years. You need to know what improvement looks like.
1000000 lines of bad code is a bit of an exaggeration. Many (most?) programmers never write that much code in their entire careers. I've heard 10000 LOC as a milestone for REALLY learning a language (once you're familiar with programming in general), I'd say it's on that order of magnitude for writing non-terrible code in general.
The problem is that a lot depends on what kind of problem your solving, and whether it varies a lot. I've written ~10k lines of python (single small project). But, I'm still at the point where it seems every other line requires me to google something, and i'm sure normal python people would snicker at the result. OTOH, I've probably written close to 750 (maybe a million, aren't small companies cool!) lines of C/C++ over the last 20 years and that is probably not enough either. Although I rarely even have to think about the code, rather i'm totally working at the algorithm/interaction level and the text pops out of my fingers.
I would say 10k is enough that you can put it on your resume... But, even that is probably way less than the average comp-sci graduate writes. So, I would still consider it a starting point. Especially, since reading other peoples code is just as important a skill, and that isn't something generally picked up in school, or on little weekend projects using a new language.
But again, it depends on the breadth of the problems being solved. We hired a web developer a couple years ago, who in the space of about a year wrote ~150k lines of PHP and javascript, and got a _LOT_ better at it, but he solved most of the problems the same way and there was a metric ton of duplicate code, and imprecise problem solving (AKA problems solved in the most roundabout way). Over the last 2 years I've probably only written about 50k lines of PHP/Javascript but I've added about 20x the functionality he added. So, I would say that i'm better now than he was when he left, but i'm still not really that good.
I'd hate to see my old VB4 code I wrote back in the day. I'm sure I did worse, except at the time I thought I was a rock-star. Of course it was the late 90's and everyone who had a compsci degree was a bad-ass developer no matter what language you used or how many bad lines of code you wrote.
I remember reading some advice like this around the time I started programming. It was something along the lines of "every dev has XXXXX lines of bad code in them, so write a lot of code to get them done with!". (I think it was from Joel Spolsky, IIRC.) It helped motivate me to just write a ton of code, even early on when I didn't really know what I was doing. Just writing a bunch of code without worrying too much about if it's "right" or not is really important, at least early on.
I think I write better code now because I spent so much time just writing stuff early on, and learning from my mistakes. That, along with some good mentors helped me so much more than the people that merely criticize you because of your code. I definitely agree with this article.
The xkcd thing is just one webcomic, I reckon it is just a joke and probably Randall Munroe did not consider its implications or think it would be taken seriously. Though xkcd is really popular and probably is relatively influential (especially in programming circles)
That being said, I totally agree with this article. Also 'read a style guide' is one of the worst possible suggestions I could think of. Style is just style. Its one of the least important things I could think of. It depends on your work situation but in many cases why not just go with whatever style you are happy with personally and makes sense to you.
What if you are an experienced engineer talking to another experienced engineer ?
Seems to me if someone writes bad code when they SHOULD be writing good code, code-shaming might be in order.
I'm all for being nice and understanding. Everyone programs at a different level and I may not write code that is as good as I think, but some code is just obviously bad...and constructive criticism (if willing to be accepted) might help
Yeah, you shouldn't shame people because their code is bad. But the other side of that is when someone says your code is bad you don't take it personally. There is more than one way to not be a nice person.
Just think, if everything is pretty good and isn't that bad and doesn't need that much improvement, why should anything ever get any better, ever?
This times a million. I love helping people to learn C, for example. And the thing I do most other than basic instruction is helping to keep their spirits up and reminding them that refactoring is the most important part of coding.
one of my first projects as a consultant fresh out of college was HORRIBLY coded by my standards today. Sometimes I still fire it up and it still works (which fills me with pride); however, perusing the code hurts my eyes and I often wonder what was going through my mind.
Bad code is a great wedge for business people to get programmers obsessed with individual relative ranking and prevent any sort of collective action.
I certainly had jobs in the past where I got angry over bad code when, in fact, I should have been bad at the businessmen making me use the bad code (instead of putting time on the calendar to write things properly) and setting the deadlines that caused the bad code.
For sure, there are some sloppy, borderline-unethical engineers who write shitty fast code to get promoted away from the maintenance messes they generate... and there are definitely some incompetent engineers. For the most part, though, bad code is a symptom of bad leadership rather than bad programmers. Under a tight enough deadline, everyone's code will be shit.
And, of course, it goes without saying that the proper response to bad code isn't to flip out on the person, but to teach him how to do it better. One of the reasons why I like using high-productivity languages like Haskell rather than Java is that it selects for people who genuinely want to improve.
Windows ME? In all seriousness I've witnessed people shame over bad code, yet later when other people looked at their code was just was bad. We all write bad code, hopefully we're able to make it less bad the more we write it.
Factually incorrect. Creating new strings by concatenation requires reallocation because Strings are immutable in java. Using a Builder is over 700x faster:
This is true, javac only replaces individual concatentations with use of a StringBuilder, so foo + bar + baz + "!" is fast, but performing a concatenation in a loop does multiple copies for each iteration. It (or the JIT) could conceivably do escape analysis to optimize simple cases like this, but it doesn't.
Why don't you give it a try yourself. Create a file with a high ratio of lines to length, and read it in using a loop and string concat, or builder. Do it with a builder first, when you get up to 1 minute, switch over to concat and see how long it takes.
But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enough if you follow it with a "but".
"Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work"
will get better results then this
"Hey pretty cool program, but you're reading in files wrong"
which even that is better than this
"You're reading in files completely wrong, try googling for a better solution" which unfortunately among engineers seems to be the most common reply.