21–30 of 105 posts
Every time someone breaks something, we get harder to break.
This my favorite interview question to ask candidates:
"What is your all time biggest screw up, and how did you come back from it" - I then tell them the story of me loosing several hundred thousand dollars and the funny things that happened around it to set the tone. If you have been in tech for any length of time you have one of these stories (if not a few). I have heard some great ones by simply asking and it gives great insight into a candidate (humor, stress response, the things you have seen).
I like this site and hadn't really read much from it - it's interesting how much it's been front paged over the last couple of weeks: https://news.ycombinator.com/from?site=rachelbythebay.com
Rachel is an excellent writer who was on a long break from writing. Seems like HN is happy to read her posts again.
Also, there are many more stories to be told now!
My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…
When it is all said and done, if you fucked up, you should get some shit for it. However this should be good natured, YOU should be laughing at it and everyone else laughing WITH you.
The best programmer vs the worst user, and every mix in between, shall produce situations needing attention this article addresses.
I've been in this situation on both sides. "Of course it should be clear what this phrase means, how could they fuck this up?" ... and ... "I have on idea what this means, both choices could mean what I want but either choice ends me up on the wrong page of this bullshit 'choose my own adventure' that I'll have to repeat if I'm wrong".
I'm interested in finding out if I'm understanding this wrong, and//or other thoughts.
I used to think this way until I started working with someone who was nearly always the one who broke it. At some point we just had to face the fact that his work was unreliable even after significant mentoring. If the tasks were difficult that would be one thing, but I'm talking about stuff like committing code to prod that was clearly never even executed once.
Earlier quoted context omitted.
Rachel is an excellent writer who was on a long break from writing. Seems like HN is happy to read her posts again.
Thanks! I was working a "real job" from about mid 2013 and am no longer, so my cycles are now all mine again. I was too tired to write most of the time before. Also, there are many more stories to be told now!
My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…
We don't touch production. We don't upgrade. We are are a X million company we can't afford the risks. These are some of the excuses they put up. And then they sit 10 years or more with that bad stuff in there, build even uglier ways around it. But the time comes to actually do something about. And what was once a one day job becomes "we will hire a consultancy firm to guide us".
Outsourcing of blame - as a Service. Where's my VC???
*Obviously with the caveat that some people are repeat offenders who are careless or just not good employees
If a programmer has a habit of sloppy code, or violates the team's standards in some ways, then a good leader will keep track of the fact that one person is responsible for a recurring pattern of mistakes.
I absolutely agree with Rachel By The Bay, that many bugs arise from the complexity of the situation, and it would be wrong to blame the person who just happens to trip over that bug. But a good leader should take action against anyone who repeatedly screws up, and who seems unwilling to improve.
I've written about this before. This is from "How To Destroy A Tech Startup In Three Easy Steps":
----------------------
Wednesday, July 15th, 2015
I got to work at 11:00 a.m. John announced that our demo had stopped working. Sipping my coffee, I logged into the server to find out what the problem was. I looked at the error log for the API app, but it seemed okay. Then I checked the error log for the NLP app.
java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1955) at Celolot.nlp.Extractor.fuckBitchesGetMoney.java:87
What the hell was this?
“FuckBitchesGetMoney”?
What kind of name is that for a function?
A computer programmer can name their functions anything, but there are some “best practices” regarding names, and this particular function name violated all of them.
I asked Sital why he had given this name to his function. He looked at me straight, shrugged, and stated that the name was from the 1995 song by The Notorious B.I.G., “Get Money.” I replied that rap lyrics were not part of our naming conventions. He promised that he would change it.
Coming from anyone else, I might have interpreted the function name as an act of angry rebellion, but Sital was too forthright for that. Apparently, he thought the name was funny and went with it because he wanted to add some humor to his code. Never did he stop to think it might be unprofessional.
I looked through his code and found several other functions that had inappropriate names. I sent him a list and asked him to change their names to something standard.
A week later the function was still there. FuckBitchesGetMoney. Yet I don’t think that any of this was a deliberate act of rebellion. He was just oddly forgetful and disorganized.
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...