Best colleague: How to maximise your work. Never waste work. Everything you do, from a simple note to random thought can be turned into a blog post, conference session idea, new feature or even a whole product. Always find a use for it.
Ask HN: What lessons did you learn from your best or worst colleagues?
191–200 of 270 posts
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#192I learned from my best colleagues: success is about trust. Nothing pays better dividends than being humble, being right a lot, and doing good work. This builds allies and allies build careers. I learned from my worst colleagues: don’t assume that anyone will protect you from toxic or abusive people. You must be willing to protect yourself. When people come for you and your project, either be willing to throw down (me…
> This builds allies and allies build careers.
Compliment people behind their back relentlessly.
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#193Earlier quoted context omitted.
This is exactly why we don't put @author comments in our code. Once the code is in the main line it's owned by the team. It also helps to promote quality within the team because if you see something unreasonable you are empowered to take action (that may not be possible immediately because we all have our day jobs but at least adding a TODO for it) The standard you scroll past is the standard you accept.
This only works if the team has a very high standard and some self restraint. Otherwise notorious code churners who are addicted to a high commit count plow through the code base, regardless of whether they are area experts or not. If you contradict them, they cite the common ownership rule and paint you as a non-team-player. If they introduce bugs into the release and you point it out, you are the villain again. All…
Very interesting stuff to read from the perspective of an unenlightened outsider.
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#194Best: We do not speak of mistakes in the active voice ("Stavros made a mistake and added a bug"). We use the passive voice, or the collective "we" ("a bug was mistakenly committed to the code"). Assigning blame only hurts the team, and you should be reviewing each other's code and actions anyway. Worst: Sucking up to people and repeating competent people's advice can get you a looong way up to being a C-level while t…
I find the active voice makes it much more clear what is happening. But I do agree that assigning blame needs to be avoided so people are comfortable dissecting these issues. I think the key point is just removing names entirely. "An engineer introduced a bug" or "The on-call adjusted the setting". Having read through many a post-mortem, I cringe every time there is a section using the passive voice heavily. It conjures up an image of a cursed system where awful things descend from the heavens and the engineers are powerless to do anything about it.
Reading through a post-mortem with the active voice makes a much more clear picture to me. It becomes easier to understand the events that led to a problem. From there the key is to figure out "Why did the system not prevent this mistake".
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#195Best: in my first role, shadowing an experienced contractor, after I quietly suggested the company was a little disorganized, "Don't worry, they're all like that." Also memorable was in one of my first contract roles from another, excellent, contractor, "Spend half the day on their stuff, and half the day on your own work. You don't want to raise their expectations." To clarify that last bit of advice: a contractor s…
In my first team at a certain FAANG company, we would never schedule for more than 4 hours a day of coding per dev. Realistically that’s about the time you have thanks to meetings, code reviews, planning, other administrative activities, and working on automating parts of your job.
I particularly like, "automating parts of your job". I wish more organisations made that effort. Especially in large financial enterprises I frequently see the same manual jobs being performed every week because they won't take the time to script it. They'll write up the manual steps, sometimes, but they won't script it, and often it's not even written up.
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#196Earlier quoted context omitted.
You can also walk out of pointless meetings if they like you
That hasn't really happened at my company. They say it but it's tricky to do. If you don't do it right, they think you're pompous or something.
The trick is not to show up at all. Most pointless meetings have too many participants. Meetings with fewer than 5 people tend to actually matter. Not 100%, but that's the trend. So the majority of pointless meetings you just...don't attend. It's incredibly rare for anyone to ask where you were, and if they do, have an excuse. "Outlook must not have popped up the notification for me", "I had a conflict", etc.
If outside of that you suspect it's going to be pointless, dial in. That way even if you can't just walk out, you can do something else.
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#197Background: I worked at a very toxic startup that was run like a high-school where there was a lot of drama, backstabbing and everyone was trying to be the cool/popular kid. I learned a tonne there, especially about the type of person I don't want to be...
Best: Focus on the project and making it good. If you are correct in your ideas then good. If you are wrong but the project is better then good, everyone wins.
Worst: "perception is reality", coming from a COO that had no idea about technology and what people do but they were second in command and making a lot of decisions.
It taught me that you have to play the game and sell your accomplishments so that upper management sees you. You do not have to market yourself but do not complain about not getting credit for the amazing things you do if you do not sell yourself.
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#198Best: We do not speak of mistakes in the active voice ("Stavros made a mistake and added a bug"). We use the passive voice, or the collective "we" ("a bug was mistakenly committed to the code"). Assigning blame only hurts the team, and you should be reviewing each other's code and actions anyway. Worst: Sucking up to people and repeating competent people's advice can get you a looong way up to being a C-level while t…
As a team lead, I try to assign success to the team ("they") and blame to me when possible (or the team, never a person publicly). I _think_ a soccer coach does this (want to say Bielsa) "the boys won the game" never "I won that game".
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#199Best: We do not speak of mistakes in the active voice ("Stavros made a mistake and added a bug"). We use the passive voice, or the collective "we" ("a bug was mistakenly committed to the code"). Assigning blame only hurts the team, and you should be reviewing each other's code and actions anyway. Worst: Sucking up to people and repeating competent people's advice can get you a looong way up to being a C-level while t…
I find the active voice makes it much more clear what is happening. But I do agree that assigning blame needs to be avoided so people are comfortable dissecting these issues. I think the key point is just removing names entirely. "An engineer introduced a bug" or "The on-call adjusted the setting". Having read through many a post-mortem, I cringe every time there is a section using the passive voice heavily. It conju…
Yeah, overusing this is awkward. The main point is not to assign blame, agreed.
Re: Ask HN: What lessons did you learn from your best or worst colleagues?
#200Best: It was a lesson I got as a fresh grad. I was losing sleep over stress from work. "This is just a job," an older colleague told me. In reality, he really did his job -- he was always on time, his code was impeccable, and he used cool logic to solve any problem. And yet, he was never too emotionally attached to work. He always welcomed criticism of his work. He had the demeanor of a cool-headed hitman finishing h…
> He always welcomed criticism of his work. What are some ways to do this effectively?
This is all going to vary from workplace to workplace, but:
1. Proactively ask individuals for code review.
2. Thank people, visibly and publicly, when they point out mistakes or offer good suggestions.
3. Be an example when you leave critiques; accept that beyond some agreed-on code standards, some things are subjective. Just because you wouldn't write code in a certain way doesn't mean the way they've written it is wrong.