I grew up on military bases around military people, and in that environment I learned one bit of wisdom that has helped me many times when managing people:
If you're in charge, and your people screw up, it's not their fault. It's yours.
Yes, they made a mistake. But why did they make it? Did you not train them sufficiently? Did you not give them the mentoring they need? Did you fail to get important tools or information to them? Did you put them in a position of greater responsibility than they're currently equipped to handle, or where their skills don't match the needs of the position?
At first when you try to wrap your mind around this line of thinking, it can be difficult. Why should I be held responsible when Jack the Junior Coder is the one who actually screwed up? But eventually, if you stick with it, you learn something important: on a real team, who screwed up is irrelevant. If one person fails, the whole team fails. And your job as a leader is to help your people get to a place where they fail less and less every day, not to pin blame.
This is the difference between a manager and a leader: a leader is someone who accepts responsibility not just for his own actions, but for his team's as well.
"If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders are clear, and the soldiers nevertheless disobey, then it is the fault of their officers." - Sun Tzu
I think startups have a lot to learn from the military community. Yes, for the most part modern militaries are extensive bureaucracies, but military thinkers and intellectuals are really at the forefront of management science. John Boyd basically wrote The Lean Startup 30 years before Eric Ries did.
In case of military, they trained the guy/gal who screwed up. In case of a startup what if the new recruit screwed up? He/she is a couple weeks old to the place and how can the leader be responsible for a screw up of a person who has only been there for a few days?
The idolization of Steve Jobs has a lot of issues, and this might be a good example of one. We don't know whether Apple succeeded in spite of or because of Steve's management behaviors.
It's also worth noting that the original Mac (the same time period most of those 'crazy Steve' stories originate from) was a huge commercial 'meh'.
Not to mention NeXT, which also had its share of "crazy Steve" management, and which would have been an unmitigated failure if Apple hadn't bought them out.
If you're interested in that story, Randall Stross' book Steve Jobs and the NeXT Big Thing (http://www.amazon.com/Steve-Jobs-Next-Big-Thing/dp/068912135...) is a good telling of it. (It was written before Jobs' return to Apple and subsequent huge success, so it's a fascinating artifact of the time before he became Saint Steve.)
Wow, a surprising number of comments on that blog post agree with the manager.
Ya, it's a stupid bug, but the way the manager dealt with it was totally out of line. Whether or not that "style" of management results in better output is moot, you just don't treat people like that. It's not like the developer shot the manager's dog or anything.
I hope no company YC makes this mistake, considering How to Win Friends and Influence People [0] is recommended reading in YC [1].
For example: Don't criticize, condemn, or complain. and Let the other person save face.
That is, criticize in private, give praise in public (give the person a fine reputation to live up to). Calling someone a retard is a counter-productive thing to do.
Similar humiliations used to happen to me at my first job. It was the first time I was programming professionally and made a few mistakes that would've cost the startup a lot. On my second week opn the job, I commented out, by mistake, the initialization of variable $user (arrrgh!!). The website crashed on all the signed-in users. My boss being the stressed nerv-ball that he was crictized me in the same way described in the article.
I think there's a lesson to be taken here. Not for managers (clearly good management would criticize privately) but for the employee. Learn to take a yell. It's not good style but it's widely common, people above you scream at you when you screw up. Learn not to take it personal, and not to let such incidents affect your passion for your work. The yelling is bad form, but it's not direct criticism at you. In large entreprises, it's the result of a chain of screaming starting at the top. In startups it's the result of the nerve-wrecking stress, founders go through.
'Constructive criticism' is an advice we give would-be managers, but it's a luxury starting employees rarely get. You're lucky if you meet one such boss in your career. Learn to take criticism, the bad kind, leaving out the humiliation. I found the best way to cut a yelling short is by answering loudly: "You're right I screwed up, I'm sorry. At least now I learned it, it won't happen again". After getting yelled at like this a few times, you'll realize it's really not against you, and such an answer would calm down your boss quickly; make sure not to make that mistake again, because then you'd really deserve a humiliation ;). This is easier said (written?) than done, but it's a natural part of one's career. I take it as a mental strength test.
Also, you won't be the junior on the team forever. One day you'll be responsible for an intern screwing up. Remember that moment and don't be too harsh.
> On my second week opn the job, I commented out, by
> mistake, the initialization of variable $user (arrrgh!!).
> The website crashed on all the signed-in users.
I'm trying to imagine a professional, well run software shop that would actually hold you responsible for this. I can not. It seems to me that for this to have happened, many things must have gone wrong, or many professional practices must have been completely missing:
1.) there were no code reviews
2.) there were no unit tests
3.) there were no functional tests
4.) no one noticed any problems on the development site
5.) there was no QA person, or the whole QA team somehow failed to test this
6.) there were no 3rd party testing services that might have caught this (like Airbrake), nor any in house error logging services (errbit)
I could go on. I'm trying to imagine how a programmer comments out the $user variable and that change makes it all the way to production without anyone noticing. I think a lot of things have to wrong, all through the organization, before that becomes possible.
I read your story and I have 2 quick thoughts:
1.) I have made many worse mistakes (thought I was changing database password for dev, in the config file, but actually changed it for production)
2.) None of my worst mistakes ever made it to production, because the company had some process that caught them before such a change ever got pushed to production.
No programmer can avoid mistakes. That simply isn't possible. To insist that a programmer always write perfect code would be like insisting that an NBA basketball player make 100% of his 3 point shots: the world would be a very different place if it was possible to insist on perfection.
A well run organization has multiple checks that ensure mistakes made in development don't make it to production. Any organization that puts 100% responsibility on one programmer is taking a 100% certain risk that eventually some terrible mistake will make it to production.
Some organizations put more responsibility on individual programmers and some organizations put less. That is fine. A range of strategies can be defended. But if an organization wanted to shift most of the responsibility onto a single programmer, then they would also have to give that programmer broad latitude regarding time, so that the programmer can implement whatever they feel is necessary to ensure the robustness of the code (for instance, unit tests, functional tests, setting up automated uptime checks, etc). I'm guessing, from what few details are written above, that the above commenter both had responsibility for the code but was also under pressure to move quickly and shove stuff out the door. Under such circumstances, management needs to take 100% responsibility if something goes wrong.
Now I will qualify everything I said above with an anecdote: In 2005, when working at monkeyclaus.org, we had a little startup where I was the only programmer and we would push my changes straight to the "live" site. But we hadn't really launched yet and the few dozen users we had were just friends of ours, so the "live" site was really a "dev" site.
I can't believe that you are actually accepting this abuse and recommend to others to just suck it up. Management has a lot of responsibilities. Screaming at their subordinates isn't one of them.
I had extensive experience with bullies in school and let me tell you being submissive or showing fear of any kind only brings out the worst in them. I know you can't throw the boss against the wall (which would get a school bully of your back) but at least don't make it worse.
And no, I hope you will not stay long enough in a place like that. There are better jobs elsewhere. Shoveling shit isn't as bad as that.
Of course if it was a one time thing and the manager apologized (in public) that is another thing.
That's not just startups where that happens. Senior developers, especially the "man in a box" geniuses that don't work well with anyone else are downright abusive of other developers (and God help the poor customer support or QA people that talk to them).
On the other hand, guys I really respect just call those "rookie mistakes" and expect them to happen. Hopefully you catch them in code review before customers are impacted.
Humiliation is poison in a work environment. There is no quicker way to make people resent their jobs, stop interaction, create hate and mistrust and send a signal that "you don't matter".
I would think the code base suffers as well. I'd tend to avoid code reviews, or at least not actively seek them out, if public humiliation was par for the course.
While I totally agree with you, this example goes beyond that. Whether it's in public or in private, calling someone a "retard" and asking them how they could do something "so fucking stupid" is inexcusably abusive and a reason to quit on the spot, at the very least.
I would also add "don't be a complete asshole" as an additional requirement. Obviously that was not good code, but good managers encourage people to make mistakes so they can learn from them (as long as it isn't mission critical stuff)
Unfortunately I've done something similar to this to some outsourced contractors in India as we were doing a final code review of their deliverables. I regret it still and have tried to make amends. On the one hand we're paying them good money to do work we don't have time to do ourselves so at the time I felt it was ok and warranted. On the other hand they're human beings just like me with feelings and pride and i took them down a notch in front of their peers. Yes, I'm a better coder than them, yes we were paying them lots of money for work I felt should have been better. But the way I went about it was totally wrong. Sucks but at least I learned from it.
One of W. Edwards Deming's "Lesser Categories of Obstacles" contends that the system designed by management is responsible for 85% of mistakes and unintended consequences in a business, while workers are responsible for about 15% (src: https://en.wikipedia.org/wiki/W._Edwards_Deming#Seven_Deadly... ). Deming's 8th Point of Management is to drive out fear so that everyone can work effectively for the company (src: https://en.wikipedia.org/wiki/W._Edwards_Deming#Key_principl... ). Publicly humiliating the programmer seems to be simultaneously disregarding the symptoms of a systemic issue (namely, a lack of code reviews) and putting everyone on the team into a state of fear.
In the UK employers have a legal duty of care to protect their employees from harm in the workplace, and this includes stress.
This is written in law, and has been supported by court cases.
One incident like that is wrong, but could perhaps be explained by someone having a really bad day. Recognition, apology, and no further incidents would help.
But continued incidents? The company is leaving themselves open to lawsuits. ("Constructive dismissal" and employment tribunal in the UK.) I'm pretty sure that toxic work environment leading to poor health is something that has been through US courts.
I mention this because sometimes the only way you get through to PHBs is to talk about costs and risks, and not "don't let employees be dicks to other employees".
I'm not agreeing in any way with the manager in this situation; public humiliation of employees by managers is both morally cowardly (bullying someone from a position of power) and ineffective over the long run (in my opinion). But still, stress happens in most jobs. Often times it is caused by a combination of home and work factors. It's ridiculous to make "preventing stress" a legal duty of employers, because that's not wholly within an employers control. Example: Faulty machine used to serve customers blows up at work at now you have a lot of angry customers. Stress ensues.
The people on that page that are saying the abuse as well deserved are part of the problem.
Sure, it's not good code, and causes problems in production. It's certainly not the right way to do this -- but constructive criticism, gentle corrections, and rewards/acknowledgements of successes when they occur are far more effective in the long run than this public tirade bullshit. AFAIC, the PM that humiliates an employee in public for any reason is (a) immature, (b) short-sighted, (c) unprofessional, (d) a poor choice for a PM, and likely (e) insecure and feels the need to strut his/her intellectual "superiority" in front of others lest their authority/superiority be called into question.
I also would have quit on the spot -- life is far, far too short to deal with that kind of crap, and there are other work environments in our field where one can do what one enjoys and where it's okay to be a fucking human being instead of being viewed as merely a code generation resource that can be kicked around when it doesn't "behave."
The proper response to that kind of public humiliation is "Okay, you're right, it was a pretty stupid thing to do. But not as stupid as abusing your employees and creating an environment where the primary motivators are grounded in FUD. I'll collect my things from my desk because...how to communicate this part adequately...oh yeah: fuck you."
> "How many times do you think the client can connect to the DB per second? Thousands!"
Is this a source of concern for the DB? If it is, you might want to consider limiting connections on one side or the other at a deeper level. Self-inflicted DoS bugs during development aren't fun, but actual DoS attacks in production are even less fun. If there's a potential way to bring your DB to its knees and you get popular enough for trolls (let alone actual crackers) to take notice (and if you're writing video games that presumably have high score boards or something similar this isn't that unlikely) expect people to find it.
It's good to get yelled at some number of times throughout your life to help you grow a thicker skin, but I've never been yelled at in the work environment. If it occurred I'd be strongly motivated to quit like others here. Stating matter-of-factly "That was stupid" is one thing, joking and exaggerating stupidity of yourself or others is another (and is dependent on implicit understanding of such and also requires a certain culture of the group), but when it gets to a manager actually screaming at you about a possibility of something bad happening then that's the line, at least for me. If I wanted to get screamed at, I'd join the military.
Speaking of awful code. 17 days ago, when the new Galaxy "demo" page launched from Samsung, they had that webpage, www.tgeltaayehxnx.com with the countdown.. you guys remember?
Anyway, I was interested to see what was happening with that page out of interest so I checked out the source.
What I found made me laugh so hard. Given the fact that I knew that second perfect cache invalidation is pretty hard...and given time zones... I knew that this wouldn't end well. What happened as a result? They created their own distributed denial of service that was set to fire off every connected user at the same time. They ended up taking down their new launching page for their phone.
This was the code:
if (timediff < 0) {
//console.log("LIVE!");
location.reload(true);
} else {
// Do stuff.
}
Whoever wrote that code, was basically checking if the time difference between the countdown was zero and then refresh the page. Guess what? This ran continuously. For thousands of clients...
I wonder what kind of jokes they had at Samsung over this one.
Code reviews are just opportunities for institutionalized bike-shedding.
And in cases like this ensures further humiliation.
Instruction can work, but it requires a smart programmer who can do it right. Collaboration can work but it reduces the speed you can think at to how fast two people can communicate instead of how fast one person can think.
And no, I don't have good solution (other than to ensure you only hire the best people).
Please can you increase the font size on your blog? Not only does small size font make no sense, it is also unreadable for me (chrome, Windows): http://i.imgur.com/TZUVi.jpg
Anywhere from 16px to 22px would be fine, we are here to read the text afterall. It's the focus!
> It makes me sad to see recent portrayals of Silicon Valley hold up humiliation as a recipe for success.
This is an interesting statement in the article and I think it is worth bringing up. It contrasts significantly to the other article I just read that said that "public shaming", which is just another word for public humiliation, is a desirable practice needed to stem the existential threat to engineering of "brogrammers".
A much better approach (from a piano teacher, but it generalizes:
Tags like "stupid," "bad at ____", "sloppy," and so on, are ways of saying "You're performing badly and I don't know why." Once you move it to "you're performing badly because you have the wrong fingerings," ... it's no longer a vague personal failing but a causal necessity. Anyone who never understood limits will flunk calculus. It's not you, it's the bug.
[+] [-] smacktoward|14 years ago|reply
If you're in charge, and your people screw up, it's not their fault. It's yours.
Yes, they made a mistake. But why did they make it? Did you not train them sufficiently? Did you not give them the mentoring they need? Did you fail to get important tools or information to them? Did you put them in a position of greater responsibility than they're currently equipped to handle, or where their skills don't match the needs of the position?
At first when you try to wrap your mind around this line of thinking, it can be difficult. Why should I be held responsible when Jack the Junior Coder is the one who actually screwed up? But eventually, if you stick with it, you learn something important: on a real team, who screwed up is irrelevant. If one person fails, the whole team fails. And your job as a leader is to help your people get to a place where they fail less and less every day, not to pin blame.
This is the difference between a manager and a leader: a leader is someone who accepts responsibility not just for his own actions, but for his team's as well.
[+] [-] nateberkopec|14 years ago|reply
I think startups have a lot to learn from the military community. Yes, for the most part modern militaries are extensive bureaucracies, but military thinkers and intellectuals are really at the forefront of management science. John Boyd basically wrote The Lean Startup 30 years before Eric Ries did.
[+] [-] Achshar|14 years ago|reply
[+] [-] nateberkopec|14 years ago|reply
It's also worth noting that the original Mac (the same time period most of those 'crazy Steve' stories originate from) was a huge commercial 'meh'.
[+] [-] smacktoward|14 years ago|reply
If you're interested in that story, Randall Stross' book Steve Jobs and the NeXT Big Thing (http://www.amazon.com/Steve-Jobs-Next-Big-Thing/dp/068912135...) is a good telling of it. (It was written before Jobs' return to Apple and subsequent huge success, so it's a fascinating artifact of the time before he became Saint Steve.)
[+] [-] JVIDEL|14 years ago|reply
[+] [-] jonny_eh|14 years ago|reply
Ya, it's a stupid bug, but the way the manager dealt with it was totally out of line. Whether or not that "style" of management results in better output is moot, you just don't treat people like that. It's not like the developer shot the manager's dog or anything.
[+] [-] oskarth|14 years ago|reply
For example: Don't criticize, condemn, or complain. and Let the other person save face.
That is, criticize in private, give praise in public (give the person a fine reputation to live up to). Calling someone a retard is a counter-productive thing to do.
0: https://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influen...
1: http://news.ycombinator.com/item?id=5584 (can't find where I read it, but this thread points to pg recommending it)
[+] [-] qbproger|14 years ago|reply
[+] [-] babarock|14 years ago|reply
I think there's a lesson to be taken here. Not for managers (clearly good management would criticize privately) but for the employee. Learn to take a yell. It's not good style but it's widely common, people above you scream at you when you screw up. Learn not to take it personal, and not to let such incidents affect your passion for your work. The yelling is bad form, but it's not direct criticism at you. In large entreprises, it's the result of a chain of screaming starting at the top. In startups it's the result of the nerve-wrecking stress, founders go through.
'Constructive criticism' is an advice we give would-be managers, but it's a luxury starting employees rarely get. You're lucky if you meet one such boss in your career. Learn to take criticism, the bad kind, leaving out the humiliation. I found the best way to cut a yelling short is by answering loudly: "You're right I screwed up, I'm sorry. At least now I learned it, it won't happen again". After getting yelled at like this a few times, you'll realize it's really not against you, and such an answer would calm down your boss quickly; make sure not to make that mistake again, because then you'd really deserve a humiliation ;). This is easier said (written?) than done, but it's a natural part of one's career. I take it as a mental strength test.
Also, you won't be the junior on the team forever. One day you'll be responsible for an intern screwing up. Remember that moment and don't be too harsh.
[+] [-] lkrubner|14 years ago|reply
> mistake, the initialization of variable $user (arrrgh!!).
> The website crashed on all the signed-in users.
I'm trying to imagine a professional, well run software shop that would actually hold you responsible for this. I can not. It seems to me that for this to have happened, many things must have gone wrong, or many professional practices must have been completely missing:
1.) there were no code reviews
2.) there were no unit tests
3.) there were no functional tests
4.) no one noticed any problems on the development site
5.) there was no QA person, or the whole QA team somehow failed to test this
6.) there were no 3rd party testing services that might have caught this (like Airbrake), nor any in house error logging services (errbit)
I could go on. I'm trying to imagine how a programmer comments out the $user variable and that change makes it all the way to production without anyone noticing. I think a lot of things have to wrong, all through the organization, before that becomes possible.
I read your story and I have 2 quick thoughts:
1.) I have made many worse mistakes (thought I was changing database password for dev, in the config file, but actually changed it for production)
2.) None of my worst mistakes ever made it to production, because the company had some process that caught them before such a change ever got pushed to production.
No programmer can avoid mistakes. That simply isn't possible. To insist that a programmer always write perfect code would be like insisting that an NBA basketball player make 100% of his 3 point shots: the world would be a very different place if it was possible to insist on perfection.
A well run organization has multiple checks that ensure mistakes made in development don't make it to production. Any organization that puts 100% responsibility on one programmer is taking a 100% certain risk that eventually some terrible mistake will make it to production.
Some organizations put more responsibility on individual programmers and some organizations put less. That is fine. A range of strategies can be defended. But if an organization wanted to shift most of the responsibility onto a single programmer, then they would also have to give that programmer broad latitude regarding time, so that the programmer can implement whatever they feel is necessary to ensure the robustness of the code (for instance, unit tests, functional tests, setting up automated uptime checks, etc). I'm guessing, from what few details are written above, that the above commenter both had responsibility for the code but was also under pressure to move quickly and shove stuff out the door. Under such circumstances, management needs to take 100% responsibility if something goes wrong.
Now I will qualify everything I said above with an anecdote: In 2005, when working at monkeyclaus.org, we had a little startup where I was the only programmer and we would push my changes straight to the "live" site. But we hadn't really launched yet and the few dozen users we had were just friends of ours, so the "live" site was really a "dev" site.
[+] [-] NameNickHN|14 years ago|reply
[+] [-] tomjen3|14 years ago|reply
I had extensive experience with bullies in school and let me tell you being submissive or showing fear of any kind only brings out the worst in them. I know you can't throw the boss against the wall (which would get a school bully of your back) but at least don't make it worse.
And no, I hope you will not stay long enough in a place like that. There are better jobs elsewhere. Shoveling shit isn't as bad as that.
Of course if it was a one time thing and the manager apologized (in public) that is another thing.
[+] [-] AznHisoka|14 years ago|reply
[+] [-] ja27|14 years ago|reply
On the other hand, guys I really respect just call those "rookie mistakes" and expect them to happen. Hopefully you catch them in code review before customers are impacted.
[+] [-] kanja|14 years ago|reply
[+] [-] smacktoward|14 years ago|reply
[+] [-] krober|14 years ago|reply
[+] [-] hoopism|14 years ago|reply
[+] [-] dclaysmith|14 years ago|reply
[+] [-] CodeMage|14 years ago|reply
[+] [-] ecaroth|14 years ago|reply
[+] [-] stuff4ben|14 years ago|reply
[+] [-] gpcz|14 years ago|reply
[+] [-] DanBC|14 years ago|reply
This is written in law, and has been supported by court cases.
One incident like that is wrong, but could perhaps be explained by someone having a really bad day. Recognition, apology, and no further incidents would help.
But continued incidents? The company is leaving themselves open to lawsuits. ("Constructive dismissal" and employment tribunal in the UK.) I'm pretty sure that toxic work environment leading to poor health is something that has been through US courts.
I mention this because sometimes the only way you get through to PHBs is to talk about costs and risks, and not "don't let employees be dicks to other employees".
[+] [-] justin|14 years ago|reply
I'm not agreeing in any way with the manager in this situation; public humiliation of employees by managers is both morally cowardly (bullying someone from a position of power) and ineffective over the long run (in my opinion). But still, stress happens in most jobs. Often times it is caused by a combination of home and work factors. It's ridiculous to make "preventing stress" a legal duty of employers, because that's not wholly within an employers control. Example: Faulty machine used to serve customers blows up at work at now you have a lot of angry customers. Stress ensues.
[+] [-] stevencorona|14 years ago|reply
[+] [-] intractable_|14 years ago|reply
The people on that page that are saying the abuse as well deserved are part of the problem.
Sure, it's not good code, and causes problems in production. It's certainly not the right way to do this -- but constructive criticism, gentle corrections, and rewards/acknowledgements of successes when they occur are far more effective in the long run than this public tirade bullshit. AFAIC, the PM that humiliates an employee in public for any reason is (a) immature, (b) short-sighted, (c) unprofessional, (d) a poor choice for a PM, and likely (e) insecure and feels the need to strut his/her intellectual "superiority" in front of others lest their authority/superiority be called into question.
I also would have quit on the spot -- life is far, far too short to deal with that kind of crap, and there are other work environments in our field where one can do what one enjoys and where it's okay to be a fucking human being instead of being viewed as merely a code generation resource that can be kicked around when it doesn't "behave."
The proper response to that kind of public humiliation is "Okay, you're right, it was a pretty stupid thing to do. But not as stupid as abusing your employees and creating an environment where the primary motivators are grounded in FUD. I'll collect my things from my desk because...how to communicate this part adequately...oh yeah: fuck you."
[+] [-] Jach|14 years ago|reply
Is this a source of concern for the DB? If it is, you might want to consider limiting connections on one side or the other at a deeper level. Self-inflicted DoS bugs during development aren't fun, but actual DoS attacks in production are even less fun. If there's a potential way to bring your DB to its knees and you get popular enough for trolls (let alone actual crackers) to take notice (and if you're writing video games that presumably have high score boards or something similar this isn't that unlikely) expect people to find it.
It's good to get yelled at some number of times throughout your life to help you grow a thicker skin, but I've never been yelled at in the work environment. If it occurred I'd be strongly motivated to quit like others here. Stating matter-of-factly "That was stupid" is one thing, joking and exaggerating stupidity of yourself or others is another (and is dependent on implicit understanding of such and also requires a certain culture of the group), but when it gets to a manager actually screaming at you about a possibility of something bad happening then that's the line, at least for me. If I wanted to get screamed at, I'd join the military.
[+] [-] Estragon|14 years ago|reply
[+] [-] chrisacky|14 years ago|reply
Anyway, I was interested to see what was happening with that page out of interest so I checked out the source.
What I found made me laugh so hard. Given the fact that I knew that second perfect cache invalidation is pretty hard...and given time zones... I knew that this wouldn't end well. What happened as a result? They created their own distributed denial of service that was set to fire off every connected user at the same time. They ended up taking down their new launching page for their phone.
This was the code:
Whoever wrote that code, was basically checking if the time difference between the countdown was zero and then refresh the page. Guess what? This ran continuously. For thousands of clients...I wonder what kind of jokes they had at Samsung over this one.
[+] [-] parfe|14 years ago|reply
Code reviews, instruction, and collaboration help make better code.
[+] [-] tomjen3|14 years ago|reply
And in cases like this ensures further humiliation.
Instruction can work, but it requires a smart programmer who can do it right. Collaboration can work but it reduces the speed you can think at to how fast two people can communicate instead of how fast one person can think.
And no, I don't have good solution (other than to ensure you only hire the best people).
[+] [-] citricsquid|14 years ago|reply
Anywhere from 16px to 22px would be fine, we are here to read the text afterall. It's the focus!
[+] [-] aqme28|14 years ago|reply
(ctrl + mouse-wheel for me)
e: VVV Good point.
[+] [-] debacle|14 years ago|reply
> so afraid of being publicly railed-on that they wrote pretty much bug-free code all the time.
That's a non sequitur. Programmers try to write bug-free code all the time anyway. No one tries to introduce bugs.
[+] [-] droithomme|14 years ago|reply
This is an interesting statement in the article and I think it is worth bringing up. It contrasts significantly to the other article I just read that said that "public shaming", which is just another word for public humiliation, is a desirable practice needed to stem the existential threat to engineering of "brogrammers".
http://www.cnn.com/2012/05/10/opinion/trapani-brogrammer-cul...
> Sometimes the road to enlightenment is paved with public shaming.
[+] [-] essayist|14 years ago|reply
Tags like "stupid," "bad at ____", "sloppy," and so on, are ways of saying "You're performing badly and I don't know why." Once you move it to "you're performing badly because you have the wrong fingerings," ... it's no longer a vague personal failing but a causal necessity. Anyone who never understood limits will flunk calculus. It's not you, it's the bug.
http://celandine13.livejournal.com/33599.html