Live data from Hacker News

Ask HN: What lessons did you learn from your best or worst colleagues?

news.ycombinator.com

261–270 of 270 posts

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#261
post #141
post #19

Best: Good research is about the quantity and throughput of ideas you can test, not the quality of individual ideas. Worst: Code should be designed for users, not any individual engineer's philosophical preference.

The best one I understand and agree. If one tries to work only on "good" ideas he might never work on anything. Trying stuff out is super important even if it is a bit silly idea to work out. Worst, the way it is written left me a bit confused. I understood: If someone wants "perfect code" because of "software craftsmanship". Where "users are stupid" because they should learn how to use the software. It is really bad…

> Worst, the way it is written left me a bit confused.

> [ . . . ]

> Quotations mean beliefs of person having such of a approach.

You can learn how not to do something from observing someone doing things wrong.

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#262

Earlier quoted context omitted.

A single developer who can complete projects in the same amount of time as 10 or 100 or 1000 regular developers to at least the same quality standard (but usually to a higher quality standard because code quality is key to getting that productivity gain in the first place and code quality usually translates to project quality). That said there are projects for which a developer could be infinity-x compared to other r…

The problem with being a 10x or a 100x dev is that you never get paid commensurate to your value. You’re almost always better off (psychologically - unless you have mouths to feed :P) starting a business if you have business/marketing chops at all.

That's not a great option in most cases either. You need social connections or else your product will never sell.

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#263

Earlier quoted context omitted.

> You are the exception, you know that right? Sure, but I don't agree that touch typing is "the" technique and that it's impossible that someone else has come up with a better one independently. Touch typing is a good way to type well, but I don't think it's distinct from "typing", it's one way to type. Just like you can play the guitar even if you don't know the technique. > - Why do you think you did slow down afte…

I'm the same way, and the reason is simple - I played MUDs as a kid. I can hit > 100 wpm easily if my brain can keep up. Occasionally something will throw me; a weird bit of punctuation, like the shift + number keys, but that's about it. I've tried to learn to touch type, but the drop in speed, and the promise of ending up basically where I am now means I just don't care. The way I move my hands and wrists and such p…

I think speed is misinterpretted. I meant as a minimum benchmark, as in it won't be slower than your unorthodox methods once you are good at it. Not as a max. Typing words as you think them IMO beats holding your breathe and playing 3 finger whackamole to get a paragraph out while looking down at the keyboard. I have also been half way between 2 methods and glad I was able to transition over fully. As someone mentioned it also works on split keyboards.

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#264
post #219

Good managers are largely similar, but bad managers are each bad in their own way (with apologies to Tolstoy). From my good managers I have learnt the value of shielding working employees from excessive meetings and bureaucracy, and trusting people to work out their own solutions while assiting and supporting them. However, I have learnt so much more (direcly and indirectly) from my bad managers. A couple of examples…

Shielding is a tricky thing. Shielding is nice, less stuff to worry about, but also reduces transparency. In the end you're not working for your manager. Your manager will not use the thing that you are building. I would say that any mature organization doesn't need a manager to shield the team, the team should be able to that themselves.

I think shielding doesn't necessarily mean lack of transparency, if they are a good manager they should be able to provide you context and information about the bigger picture while still protecting your time and representing your interests in meetings with higher ups and peer groups.

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#265
post #143

I notice that the vast majority of comments here are lessons learned about office dynamics and interpersonal relationships. Which either indicates that soft skills are much more important than tech skills or that HN's mostly technical audience has had more to learn about soft skills than hard skills. To buck the trend, I'm going to add a few "hard skills" lessons I've learned from managers. From the best: "Every if s…

Along the lines of "hard skills" from mentors, I learned that if releasing an update from your team is 1x of difficulty, and releasing an update from another team is 1x difficulty, releasing an update that has dependencies from both teams will be 10x of difficulty, because things get exponentially more complicated once you have teams all trying to do things together.

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#266

Earlier quoted context omitted.

I'm the same way, and the reason is simple - I played MUDs as a kid. I can hit > 100 wpm easily if my brain can keep up. Occasionally something will throw me; a weird bit of punctuation, like the shift + number keys, but that's about it. I've tried to learn to touch type, but the drop in speed, and the promise of ending up basically where I am now means I just don't care. The way I move my hands and wrists and such p…

I think speed is misinterpretted. I meant as a minimum benchmark, as in it won't be slower than your unorthodox methods once you are good at it. Not as a max. Typing words as you think them IMO beats holding your breathe and playing 3 finger whackamole to get a paragraph out while looking down at the keyboard. I have also been half way between 2 methods and glad I was able to transition over fully. As someone mention…

I don't look at the keyboard, I don't hold my breath. It's perfectly natural. Playing a MUD I didn't look at my keyboard; I was watching the screen and reading lines as they went by.

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#267
post #143

I notice that the vast majority of comments here are lessons learned about office dynamics and interpersonal relationships. Which either indicates that soft skills are much more important than tech skills or that HN's mostly technical audience has had more to learn about soft skills than hard skills. To buck the trend, I'm going to add a few "hard skills" lessons I've learned from managers. From the best: "Every if s…

I appreciate this. I think one of the more valuable advice I was given re:conditionals is to make sure the positive path is the non-branching path. Branch your exception, let your expected path fall through. if ( unexpected = true ) branch; do_expected_stuff Caveat: ways to do things age. Maybe this is no longer true or even slightly advantageous, but so far it has served me. I also prefer 20 lines of simple pedestri…

I learnt this one early on and definitely still encourage it (but aware of your caveat too). But I describe it differently when I'm coaching, and I think I've used the phrase "try to get your conditionals out of the way early".

My rationale is that having done this, I'm left with a smaller combinatoric mental space to work within. Like "if the program counter has reached this point then I know for a fact that X, Y, and Z don't apply - the function would have exited early if they did". And that then means the remaining set of things I have to keep in my working memory is reduced, which makes life easier.

Is that similar to how you see this advice?

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#268

Earlier quoted context omitted.

There’s a difference between obviously absurd ideas and those that someone can go off and try in their own codebase. Giving some breathing room so people can experiment and try things on their own without disrupting the product is being supportive, in my opinion. It doesn’t mean everything should go in. But I give the person the opportunity to sell their idea. Maybe it’s better than I think, or maybe others on the te…

> Unless you’re the only competent person on the team, if the team thinks its a good idea then why not? If you’re the only competent person on the team however, you should really leave the company. Sometimes I ask myself this question and I basically can't answer because, well. What are the odds that I am ? And what are the odds that it's the opposite, their ideas are great and I am in the wrong doubting them ? Actua…

> Actually the most common situation is that someone will come with a very bad idea, and when asked what they think about it, the other attendants will something like "yeah, maybe that could work". They don't approve nor reject the idea. And it looks like more passivity than anything, but if nobody says "nope, that's wrong" and I'm convinced it actually is, maybe I am the one in the wrong ?

That’s called “The Abilene Paradox.”[0]

[0] https://en.m.wikipedia.org/wiki/Abilene_paradox

Re: Ask HN: What lessons did you learn from your best or worst colleagues?

#269
post #143

I notice that the vast majority of comments here are lessons learned about office dynamics and interpersonal relationships. Which either indicates that soft skills are much more important than tech skills or that HN's mostly technical audience has had more to learn about soft skills than hard skills. To buck the trend, I'm going to add a few "hard skills" lessons I've learned from managers. From the best: "Every if s…

I appreciate this. I think one of the more valuable advice I was given re:conditionals is to make sure the positive path is the non-branching path. Branch your exception, let your expected path fall through. if ( unexpected = true ) branch; do_expected_stuff Caveat: ways to do things age. Maybe this is no longer true or even slightly advantageous, but so far it has served me. I also prefer 20 lines of simple pedestri…

aren't these ill defined guards?
Post reply on HN