4 ms·
Smart, gets things done on time, pleasant to work with. Pick any two and you’ll do fine. Neil Gaiman’s commencement speech. I think if two are lacking for a whi
by andy_ppp 5y ago
Smart, gets things done on time, pleasant to work with. Pick any two and you’ll do fine. Neil Gaiman’s commencement speech. I think if two are lacking for a while you get fired…
- kalimanzaro 5y agoSomething tells me in the anecdata above, the unfirable characters involved picked 1 _at most_: The teflon engineers don't seem smart and probably can't get things done on time if at all. While the sensitive engineer seems unpleasant to work with, while not contributing at all. Neil Gaiman has a knack of saying immensely compelling stuff, that's all there is.
- Swizec 5y agoYou can be all 3. Lots of smart people out there doing great work who are pleasant to work with. But you gotta treat them right. Everyone becomes unpleasant in a bad environment
- YZF 5y agoI agree a lot of this depends on the environment. Are you asking people to work on things they enjoy working on? What's the team like? What's the culture like? "Smart" is maybe something that can be measured in a vacuum (though in practice it means more than just IQ) but most of the other parameters are very much influenced by the company, team, managers. I totally agree that people can become unpleasant if they're in a bad environment or pushed in certain ways. I've worked with some people that I thought were total jerks and we eventually became great friends, often the friction at work is about something stupid/situational + the general social awkwardness of many software people.
- worker767424 5y ago> Smart...pleasant to work with Does anyone have tips for having high code standards, but still pleasant to work with? I got feedback that I have high standards, but I also go to the effort of explaining why I think an approach is better in code reviews and don't talk down to people in code reviews (and got feedback saying this), but I'm not sure it's enough.
- celim307 5y agoComment on the code review but follow up privately and offer to pair. It’s extra work but it shows the contributor that you’re not just out to poke holes and make extra work, it shows you actually care about their development and progression as an engineer
- philjohn 5y agoThis - hammering someone's code review with tens of comments can put people on the back foot. Part of any good senior and higher engineers responsibilities is to lift the people around them up.
- dudul 5y agoPick your battles. Try to identify cases where at the end of the day, it doesn't matter if the code is not "the best TM". Also don't hesitate to tag your comments as "nitpicks".
- armchairhacker 5y agoif you want to enforce higher standards than your colleagues, you have to put in most of the work to reach those standards. For instance, if you think a section of a code needs unit tests, maybe write some of the tests yourself or at least suggest how to. also be modest, and make sure to frame your standards as cooperating to improve the company’s code, not competing to show you’re a better programmer the ultimate goal is to make your high standards more of an asset (“he’s improving the code”) then a burden (“he’s criticizing us and making us do more work”)
- scoopertrooper 5y agoTry and organise a workshop to set some common coding standards. Having a commonly understood standard for good is an excellent way to start the process.
- YZF 5y agoNot clear if the meaning here is coding standards as in how you name things, spaces vs. tabs, comments etc. or something else about the code. Coding standards (the style aspects) should just be solved by tooling, you don't let anyone merge code that's not to standard by having a tool verify that.