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.
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.
> 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.
> 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".
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.
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 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'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'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.
Readit News
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.
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.
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.
Just a suggestion, anyway. :)
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.
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.
Did the assigner spend enough time with the remote worker to understand the skill level?
In your organisation, is it OK to report a skill mismatch like this up the chain?
Summary: this is a management issue I think
Dead Comment
I usually hear this referred to as a "criticism sandwich": Criticism surrounded on either side with compliments.
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.
"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 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.
"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."
--Ricky Gervais
http://www.howardschatz.com/film.php?ID=3814
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... ;-)
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.
You did this on purpose, didn't you. ;)
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.
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".
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".
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.
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.
https://people.gnome.org/~michael/data/2011-10-13-new-develo... (5 page presentation)
Compare pages 3 and 4.
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 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?
You: "Err..."
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.
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!
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/
I've been writing code since 1976.
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.
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'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.
(Sorry for commenting in a form of a meme, but it really was asking for it)
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.)
[Edited for clarity, ironically.]
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.