391–400 of 458 posts
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Prima_donna I will die on this hill.
Maybe he meant pre-1958 developers, in the same way we used to use "BC" as "Before Christ"
> One Friday afternoon (...) [Kevin:] what did you learn? / [OP:] I talked about the need for proper QA. About thoroughly testing my changes. About taking the time to make sure the job gets done right. Kevin sure sounds like a great guy. But there was a simpler lesson to be learned: never, ever push changes on a Friday.
never, ever push changes on a Friday. I think this goes a little too far. I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises. Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday. http://product.hubspot.com/blog/how-we-deploy-3…
Earlier quoted context omitted.
Laughing at someone's code is like laughing at someone's painting or their novel or really any other creative endeavor. It's not ok period.
My team playfully makes fun of each other's code all the time. Every once in a while, someone does something stupid in code and we playfully make fun of that person, everyone on the team takes it in stride and our code is better for it. Hell, every now and then I stumble across some idiocy in the code base and think "LOL, whoever did it this way is an idiot". git blame. "OH, hahaha, it was me, what an idiot past me w…
As software engineers: As beginners, we're over-confident in our ability, even if we actually suck and make lots of mistakes: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect The opposite seems to become true - experienced engineers (who have learned from their mistakes) seem to be extra paranoid. I've seen also older engineers that seem to be confident still, talk a bit game, but they just never learned.…
Overconfidence is a huge benefit in playing the political game - getting people to take you seriously, managing up, interfacing with the outside world. Like it or not, humans are primed to respond to confidence; for most people, listing the dozen ways a system may fail signals that you shouldn't use the system, while for engineers, it signals that these are a dozen things to be fixed. The trick - when getting to high…
Exactly. My feeling is that while perhaps many of us learned this the hard way, well at least I did--from experience--in hindsight it seems obvious that our emotional impulses and intuitions, while albeit valuable, are not fine-tuned to success in technical careers.
Earlier quoted context omitted.
I disagree. If you have something that is of significant value to the company, you need to hedge your risk. Automation is a particular hedge. People fail, and while processes do too, they often fail less. Would you be comfortable moving something fragile by hand that is worth a lot of money? Maybe. Would you prefer if the fragile item being moved was done with an automated process that was shown to best protect fragi…
Well, "process" and bureaucracy tend to march hand in hand. I think it's easy to get carried away with creating "processes" (i.e., additional bureaucracy) when sometimes people just need to show good judgement. Pushing code right before you leave for the weekend is just bad judgement, and the guy learned his lesson. Heavily bureaucratic institutions laden with processes are not exactly known for their efficiency or p…
This was so nice to read. I think back to my very first coding internship after my freshman year of college when I messed up big time. I made a bad mistake that ended up forcing my supervisor to put down everything he was working on for a full afternoon and do an emergency fix. I so vividly remember sitting down in his office, trying to just calm down and keep it together. He never got upset or annoyed (at least he n…
Earlier quoted context omitted.
There are two schools of thought, especially in stock trading. 1) Reversion to the mean. This is what the above person believes and that this likely won't happen again. 2) Indication of a trend. The pilot is actually incompetent, and this will happen more frequently with this pilot than an average pilot.
I know you're probably not implying regression to the mean is causational, but that was my initial reading so I want to clarify for those who may not be familiar with the concept. Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean. The example of this being misinte…
Nice little read. There is that little answer in the back of my head of: "It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passi…
I feel where you're coming from, but in reality it's not like any test suite can guarantee to prevent downtime caused by bad deploys. All it takes is a little networking related bug, something that differs ever so slightly between environments, whatever, and your site could be down. I agree with the other replies that while you may be the 'technically right dev' kind of person, it still comes of as being a dick and y…
I don't expect the folks who built my house to detach and reattach the door pefectly every day, I expect them to build a house that works.
Earlier quoted context omitted.
I don't agree. I've seen some very junior people change their attitudes rapidly (for the better) when working on a team; if we wrote them off immediately we'd lose out on a lot of promising people. I was also one of those developers and have since changed my ways :)
Our definitions of "over confident assholes" may differ, perhaps? :) Absolutely however I do agree with you. If a young developer doesn't integrate into a team role immediately, that's no reason to not hire him. A lot of great developers are so great because they've spent years alone with their computers just cranking out code. So the best ones won't have the greatest social skills. But if the kid's still having trou…
The worst problems I've ever seen on teams spring from people that are arrogant and standoffish, followed closely by people that are too dogmatic about technical minutiae and best practices in the face of situations that require flexibility (my classic example is the prototyping team that spent two weeks setting up an automated testing and deployment infrastructure, even though they only had six weeks to do their game prototype).
I'd take a pleasant junior that's really green but is happy to learn how to code better over a more technically proficient asshole that needs to have manners jammed down their throat any day - tech skills can be taught to a newbie, personality cannot. People have had a couple decades to cement personality habits as junior programmers, so those are mostly fixed, whereas tech skills are super fresh and malleable.
Earlier quoted context omitted.
never, ever push changes on a Friday. I think this goes a little too far. I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises. Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday. http://product.hubspot.com/blog/how-we-deploy-3…
Pushing twice a day in that Facebook story gave me a shiver.