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

Best: 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 his job. At the same time, he was a warm human being to his colleagues, including me.

Worst: A conversation with this boss-colleague of mine would go like this:

Me: There was an urgent bug yesterday, and I fixed it.

Him: That bug was within my major commit last month. Did you fix the bug because you think I am incompetent and can't fix the bug myself?

Me: Oh, no, it was an urgent bug ticket submitted to our team, so I went ahead and fixed it.

Him: So you are saying I am useless to the team.

Me: No-no, I don't think you are useless. Quite to the contrary. You were busy doing another ticket yesterday. You know what, maybe you are right, and I should have waited and reconsidered before I fixed the bug.

Him: Oh yeah? You are being passive-aggressive now. Your behavior is very toxic and is disruptive to our team dynamics.

Me: I am sorry you see it that way. Could you tell me what I could have done differe...

Him: I am downgrading your performance review, and you would be getting a lower discretionary bonus this year.

This ended up costing me a five-figure bonus deduction.

Since then, after rising through ranks, I too became a team manager. Thanks to this lesson, I know how not to treat my team members.

To change anything you have to be responsible, empowered, and knowledgeable about it. If you only have one or two of them, seek out the others. If you can't attain all three, stop worrying about it; you can't change it.

Transparency leads to trust, but also can be abused. Be transparent in incremental steps, so that you still build trust with those that are trustworthy, and so you aren't hurt too badly by those that aren't.

Failures of people are as often due to the environment they're in as they are the people. That can be useful to not judge colleagues too harshly, and also to remind yourself you are good and capable when you find yourself in a job/role where you're unable to function.

The way to build successful products is to care about them. Stakeholders that seek to explain problems they're trying to solve and why the matter will get results; stakeholders that try to dictate solutions to dev will not. Seek out places that recognize the devs job is the 'how', and the rest of the business' job is the "what".

People who say "we're one team" and "it's not us vs them" are to be avoided. If the groups they're talking about were truly one team, such statements would not need to be made; making them is trying to band-aid over issues and misalignments rather than address them.

Be kind. Even useless assholes can become allies if they see you going out of your way to be kind to them.

I 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 (metaphorically) or be willing to walk. Bad people often don’t have bad careers, and there is no justice.

One of my mentors at the first company I worked for in Silicon Valley never said “no” to one of my ideas. He said “okay, we’ll try it out and see what happens.” He was inherently supportive of new ideas and as a junior engineer it felt very refreshing to not have to argue my way into a feature that I felt strongly about. I’ve carried that same mentality throughout my career.

My worst colleagues were the exact opposite. They didn’t listen to anything that they were advised and then when the project failed they tried to pin the blame on me. Luckily the rest of the team vouched for me so nothing happened but it left a bad taste in my mouth. There really isn’t much to learn from scumbags since it’s obvious you shouldn’t be a scumbag.

From my worst colleague: This man thought things were funny, and they weren't. I bicycle commuted to work, and he thought it funny to buzz me, passing just a few inches away from me, doing about 60mph on his street motorcycle. Another time, I was a bit stressed and needed some downtime so on my way out of the office, I said as much and added "so don't call me unless something is on fire." So, he called me, on my lunch, to tell me the building was on fire. I panicked, thinking all my coworkers lives were in danger, and told him to call 911 and get out of there now. He started laughing.

What did he teach me? He taught me that when I'm sufficiently pissed off, I can be vindictive. I retaliated more than once by doing mostly harmless things like sticking a floppy disk in his PC so it wouldn't boot, and then not helping him fix it so he could do his job (that should date this for ya...). He wasn't computer savvy, and I let him stew in it. That made me ashamed of myself later, and I have never taken the low road again. So he taught me something about myself, and I changed for the better because of it. I still vehemently dislike him and what he did, but that was a long time ago.

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 statement is death" was an adage of one. He encouraged me to think deeper about whether conditionals were really needed, and at what place they were needed. That mindset helped me write clearer and more easily testable code.

From the worst: In code, "brilliant" solutions are like poems: they're beautiful, they're terse, and they pack a lot of meaning into each line. To mid-level engineers, they have an intoxicating appeal, because they seem like a good way to flaunt their talents. But more often than not, what is really needed is the code version of ordinary prose: straightforward, with a preference for clarity over succinctness, easy for others to understand, easy to edit, and with fewer surprises and deviations from convention than a poem. Your goal should not be to impress your code reviewer with your cleverness but to impress the person who needs to maintain your code three years from now.

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:

From the manager that everone described as "he is very good technically, ....", I had to quickly learn how to smooth relationships, negotiate with, and jointly arrive at solutions with other parts of the company after my manager would bang his fist on the table, yell about having told them the correct way to do things previously and that the current problem is all their fault before storming out of the room.

From the manager that quickly grabbed full credit for anything and everything done by his team, even when he had zero involvement, I learnt how to be more considerate in making sure I gave out appropriate credit (both internally and to clients) of the people that I worked with.

Best: It's possible to go from being lowballed as an engineer at $30K/yr at the start of your career to pulling $250K plus bonuses in 10 years.

Worst: If you slather a sub in the hottest sauce available from Firehouse subs, and eat it as a way of proving how tough you are, you can be rendered useless as an employee for the next 36 hours. Very nice guy. But strange in a way not typical to engineers.

I worked as a student employee in IT at a university department for two years. Upon graduation, I had no job prospects but the department was posting a full-time job for which I was impeccably qualified (it was basically my student job and then some). I applied to it and got the job.

Some of my colleagues recognized the transition from student employee to professional, but strangely enough, my own boss never made the mental transition. She continued to treat me like a student in a number of degrading ways, offering condescending advice about preparing for my future and so on. I say this with a 20-year hindsight. I look back at the relationship and still think it was degrading. Within a year I applied to a different department where I got a fresh start and immediately was treated as an IT professional (though junior, of course).

I learned from this that some people are always going to see you like they first saw you. Your mother is going to always see you as the adolescent with the messy bedroom, even when you're 40. Your student job boss is always going to see you as a student.

There's the common adage that sarcasm needs a "tell", otherwise people might take you seriously. A group of previous colleagues taught me you actually have to go one level deeper:

Not only does your sarcasm need a tell, you need to have previously provided enough evidence that you're not actually an asshole. Otherwise, someone can be sarcastic all day, but no-one's really sure whether they're trying to be funny, or actually offering genuine asshole views coated in the plausible deniability of "sarcasm" for those who don't agree.

"I really can't tell if you're joking" is the first warning flag.

Best: Talking to people and discussing ideas will get you further than an email. Email should almost be a tool to summarise your discussion, spread to a wider audience and make sure everyone is on the same page.

Worst: That pretending you know what you are doing, never asking questions if you don't know what you are doing and having no sense of humility will lead to your demise.

Best: 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 should be capable of getting all of the day's work done in half the day (they are good at the job and they don't have to deal with the permanent employees' extra duties). The other half of the day may well be speculative work that the contractor wants to try out that will benefit the company but the management would never be able to say yes to if you asked for permission. Or it may just be real programming.

From the worst: that a grumpy agressive guy can actually be this way because he care too much. ( cute, I know )

From the best : the value of small talk and forming personal bonds with EVERY person you talk to.

The second one took me a while. We were both leader of team that worked together and things were going great.

I noticed that his team would kill for that guy.

And also that he always seems to know someone that could help. In OPS, in IT, in sales, in the competitor … everywhere.

And then I started to notice the small talk, the jokes, the patience … that makes that guys a nice person to work with.

And then I also noticed that he was leading both of the team, without that being very obvious. And I was not even mad about it. Everybody was exceeding target, we all got a nice bonus that year while having fun, why ruin it ?

I learned a lot from that smooth operator. ( all of that come on top of impeccable technical acumen. That play a role, too )

The squeaky wheel gets the grease (or raise).

Policies only matter if the people in power want them the matter. If they like you, they will break policy to benefit you (like early promotions). If you're not their favorite, they will break policy to your detriment (like basing your review on points completed after telling you not to record a bunch of work in stories throughout the year).

That you don't need to actually improve to be promoted. Being a 'yes man' is the easiest way to get promoted.

I doubt this will resonate with a lot of people because it makes me sound like a prick, but I used to share a cube with this gentleman who refused to eat his lunch anywhere but his cube. He was an Indian man, and though I like indian food well enough, I don't want my workspace to smell like any kind of food.

So, I asked my boss at the time for my own area. He said no.

That frustrated me, and I decided that the best thing to do is to grind some knowledge out of the situation. No better revenge than personal success, right? I slowly became an expert on every little makefile, shell script, Cron job, any little utility program I could get my hands on, I tried to understand it and improve it.

After a few months of this, I went to sysadmin and made a request along the lines of "I'm so-and-so, I work in DBA, I want to interview for this department, and if I I'm more knowledgeable than someone here, I'd like to challenge for that position, and I want my own workspace."

This was ~15 years ago now, it was a bit easier to get away with having one's head up one's ass back then.

Anyhow, I ended up with a role there, and 3yrs later I was the director for that department.

My cubemate never left. I'd still smell his food when I walked through that part of the building to my lunch break. I guess nobody got the last laugh, but I felt proud of myself for realizing I could improve my worth just by working hard at it and using the resources available.

Edit:

I thought of another one. Maybe six months before covid kinda jumped off, a young woman interning for me told me I don't drink enough water and challenged me to drink something like half my weight in lbs, in oz of water everyday. I've been doing it nearly every day since, and it's truly been impactful. Wish I'd done it at her age. My sleep is better, I feel more energized, and I dropped a few pounds before covid came. They came back. But nevertheless, hydration is a big deal.

Best: Catch up, or go home. There's always more to learn, and if you don't apply yourself, you will get steam-rollered and you won't even know why.

Worst: The more confident someone is, the more likely they are to be full crap. But - just because you don't like someone, or they're full of crap doesn't mean their wrong and/or you can't learn from them anyway.

Worst. I had a manager part of whose job was to review my docs (reports and bids) before they were released. Their approach to reviewing was to start at the beginning and work through a doc until they found a red flag. They then refused to go further until that issue was fixed, which significantly increased the length of the process and meant that there was invariably more stress to come on the next iteration. A lot of their review comments boiled down to "I don't like this do it again differently". And I was lucky, I was at least able to write decent English - one of their comments aimed at a co-worker was "This is the incompetent ramblings of a halfwit".

When I became a reviewer myself I resolved never to be like this. If I didn't like something, I would always indicate what change I was expecting for the next review to pass and also why the change was necessary - what specific problem was being addressed. If I didn't like something but couldn't say why, then I taught myself to not say anything at all, typically because it was a cosmetic difference in my preferences vs. the authors. I also realised that a really good technique was to have a quick chat with authors before they had done too much, especially to make sure we all agreed on the aim and purpose of the doc, and my review criteria - to avoid me introducing unexpected hurdles at the last minute. This became a good way of turning the review process into an iterative learning process for junior authors.

I was inspired by a guy from Brazil to learn to touch-type. It not on the national curriculum in the UK. I'd say well over half of UK coders can't touch-type. I can easily do 90+ words per minute without trying. I just think and my fingers wobble and words appear. It's like magic. I'd say everyone should learn.

I learned to run code without re-reading it from a bad coder. I used to spend a few mins reading code I'd written to double check it. Then i worked with a guy that just would run code, it would error, my heart would jump, but the world wouldn't explode. So I do that too nowadays a little bit sometimes. Just run the code after writing it without rereading it. It's scary but works 85% of the time. thing is you can run code twice and let the console tell you the issue often quicker than you reading it carefully. (be careful with this tip.) .i.e there's a time to do it and a time not to. i.e. if your changing some css block, you may not need to reread it 5 times before refreshing the page. but if you are about recursively rm some dir then maybe check.

Best: 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 the competent people remain at the lowest levels of the hierarchy.

Best: tactical diplomacy can be learned and is very valuable

Worst: The people who talk about others will talk about you

Best: It's okay to say you don't know something

Worst: Don't tell employees you pay them so they shouldn't have to use Google.

From worst colleague: Succeeding in our modern economy has nothing to do with ability, intelligence or work ethic. It's about luck and intimidation.

From best colleague: 10x, 100x, 1000x... developers are real. I also learned that making bold, controversial claims will yield respect dividends in the future when they turn out to be true. For one of my past startups, I was working closely with the CTO who was at least a 10x or 100x and some of the stuff he was saying seemed to defy a lot of the industry practices at the time. I didn't take what he was saying very seriously at first, but over the years, I ended up discovering that essentially everything he said was true and lead to huge productivity increases. It had a big impact on me to understand that software development is a craft which can be mastered on a whole different plane beyond what the vast majority of developers can imagine. I consider a lot of his teachings to be 'trade secrets' and I try to pass them on to other developers I care about (especially open source collaborators).

Best colleague taught me that if someone needs help, it is always worth my time to stop what I'm doing and give it to them.

Worst colleague taught me to be loyal to people and not to companies. You can be friends with people, but not companies. Friends will reward loyalty and sacrifice, companies just want you to think they will.

Worst(s):If someone is avoiding putting something in writing they are trying to take advantage of you, use you, betray you, or put you on the tab for something.

Bests: Hide your ambition the lazy will try to block you. The ambitious will try to remove you.

Best: Decisions don't get made in meetings. Tailor your communication to your audience. Be diligent and ethically consistent and people will respect you for it.

Worst: Stay in your lane.

Best: delivering high-quality work quickly matters

Worst: but it's amazing how long a person can last without doing much at all!

My best colleague: Do not panic (I’d just brought down the production env, it was partially his company). I’m still in awe of how he carefully went through the steps to resolve the problem, not hurrying at any point in time.

And it was solved in one go.

Best: be open to the proposed solutions of those under you. They aren't tainted by your own preconceived notions of how things should be.

Worst: be open to integrating the solutions of other teams, that may conflict with your own. Purity of your solution is irrelevant if others have gone in different directions already.

Kicker: these lessons were learned from the same person.

From my least effective colleagues: you always need to think about _shipping_ to a _real customer_. Projects that go on for months and years chasing technical perfection without going to prod will get a bad reputation, and cancelled. The people associated with leading the project might carry a bad smell. Big rewrites definitely fall into this categories...

From outright jerks: learn to let go. You can’t control everything, you don’t know everything, and you need to take a break from work to get some perspective.

From my favorite colleagues: put humility and service to the customer first. Be selfless with junior people. “We step out ... seeking only peace and friendship – to teach, if we are called upon; to be taught, if we are fortunate.”[1]

1 - https://www.unf.edu/~n00006757/astronomylectures/Voyager%20M...

My favourite colleague ever was the nicest, most diplomatic and considerate leader I've known. He taught me that if you're genuine and know the playing field, you really don't have to be a dick to succeed ... despite overwhelming evidence to the contrary.

My most annoying/disappointing colleague, who I was fooled into hiring into a senior position, taught me many, many lessons .. but the most positive was that speed to market trumps attention to detail 9 times out of 10. Seems obvious now!

Bad colleagues tend to come to you with far more problems than solutions. Any colleague that is constantly complaining about everything, but never suggesting solutions (nor wanting to discuss them) is a major flag IMO.

Best colleagues I have had would point out something to be fixed / improved, and immediately suggest a tentative solution. Worst colleagues would just blame others (major red flag) for any issue they encounter, and never put energy in solving them.

Best: Be practical and be focused on the domain problem instead of the surrounding tools, abstract methods, etc.

Worst: Fire them all really really quickly. People that are bad after week 2-4 will never not be bad afterwards.

Best: Trust is a two way street. When people trust each other and build on top of what others have built magical things happen.

Worst: Giving the benefit of the doubt for more than a few times will inevitably end in a disaster if the person is beyond redemption. The easiest way to recognize somone who cannot be helped and their work cannot be salvage is to look for persons that don't accept help and act like their work is perfection.

Best : My manager who appreciates everyone's time. He puts in efforts to immediately reply to anyone, takes quick decisions and acknowledges quite often. If anyone is dependent on you, unblock them immediately.

Worst : Many of the co-workers/ department heads etc. etc. have moved ranks above me exponentially and yes because of their hard work. Congratulations to them. But sometimes if I have to reach out to them or they need to reach out to me, they address me as "Sir". "Hello Sir, How are you Sir?" I feel terrible and I feel like they are mocking me for being a looser for not having achieved as much as they have.

Best: you get the most life satisfaction from working to your best ability all the time.

Worst: some workplaces allow the negative workers on the team to get away with anything.

Company loyality matters more than being good at your job.

There is a deadline or finished software, never both.

If you were a CEO once, people will hire you as CEO again, even if you were horrible.

Some tasks like interviewing and writing exams are distinct skills you can learn and might have nothing to do with the actual work you're required to do in a job.

From good colleagues - Be someone that improves your environment whatever you're put into - code, team dynamics, communication whatever. - Be relentless in pursuing something that you're convinced is worthwhile. Things and times change. If you feel something is good for you and the org, do it. Don't waste time "thinking". - Orgs have reputation inflation. If you're the same as you were last year/month/week, you've actually dropped. - Demand results and reward when you get them. Keep pushing your reports - Be consistent and be present. - Leadership is revealed during crises. Be in control when shit hits the fan. - Identify exceptional skills in your reports, sell those to the higher level organisation.

From bad colleagues - Protect your direct reports from the organisation (politics, snatching away of bonuses etc.) - Junior reports cannot function without a clear task. You need to handle the org and make sure they get it. (this was summarised in a great article - "context down, information up" - https://jacobian.org/2021/apr/19/the-fundamental-purpose-of-...) - Respect everyone and mentor juniors who look up to you. - Don't accept leadership positions if you can't actively play office politics.

Best: be competent, be kind, collaborate

Worst: be competent, be rude, don't collaborate

Worst: all it takes is one team member who is focused on finding problems rather than solutions to basically halt team progress

Best: Stay calm and recognize that long term success is more important than short term ups and downs.

Worst: Good people can sometimes land in the wrong role. Change conditions before passing judgement.

Background: 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.

I am still trying to figure out what useful purpose our Scrum Master has on the team. Lesson (maybe)? You can shuffle JIRA tickets all day and earn six figures.

Worst: anti-hero programming (the practice of obtaining job security through being the only one able to read own's super convoluted and complicated code) works only if immersed in a non-technical environment and is going to come back to bite you sooner or later.

My best and worst colleagues were at the same company.

Best colleague: Knew how to time manage. Knew what was priority and what wasn’t. She also knew half her job was managing her boss’s expectation. She was never late for any work because she knew how to manage up.

Worst colleague: A programmer that played more political games and sucked up to the boss than work. I mentioned his code was not up to par multiple times. The boss ignored me because the other colleague loved sucking up to him. He kept on talking behind my back. After I left, they couldn’t launch a product for 1 full year. Turns out I was the only one lifting the entire team.

Best: When someone asks you a question always answer something. If you don't have time, say let's reconnect later. But never leave people in limbo.

Worst: Letting toxic people get away with insults because they're good at their job.

Best:

* Be supportive and non-judgemental, not dismissive.

* Really listen, hear the other person out and validate them, even if their concept or idea sounds dumb. Personal goodwill combined with strengths in the domain go a very long way.

* Be willing to share, explain and help others understand things that are new without treating someone like a dummy.

* Be thorough, systematic and organized, and keep working to improve ourselves, our systems, and our efficiency.

* Take the effort to make personal connections, and more importantly, to nurture and grow them.

* The past is the past - though some bad stuff may have gone down, look to the future, to how we can build and grow.

* If things are not working out, make changes, get it working, and don't be afraid to cut my losses and change track.

* Take responsibility for growing myself, I am accountable for my career and well being, invest in myself for the medium-term and for the long-term, keep learning and make sure it's something strategic. Time is always limited and there are a million things where I can waste time. Figure out what gives me the best ROI and invest there. These are the sort of time and energy investments that take time to bear fruit, and when planned and executed strategically they are well worth the effort.

Worst:

* There's a huge laundry list here, and I'd rather not go into the details. Others have covered this.

You can be brilliant and kind. These things are not mutually exclusive, as some might lead you to believe. You should not tolerate assholes because of their brilliance.

I think when I try to objectively look back at my career, I was at times the best colleague, and at other times the worst colleague.

I regret looking back at my worst moments.

One exec I served under - whom was both feared and loathed by peers and underlings - had one quality that I quite admired: no matter how busy he was if I needed his input on an urgent issue the moment I sat down in his office I had his undivided attention.

He didn't double-task and constantly check his computer, phone or read/sign papers. I had his full attention while I was there.

It's an attribute that stuck with me.

Worst: they assume that others have bad intentions, particularly when those people offer help

Best: they believe others are capable of achievement, and they offer help

Avoid projects where someone who conspicuously and officially failed still has influence over, for only your failure will validate his failure.

Best: Give employees the benefit of the doubt at all times and ask what you can do to help them succeed.

Worst: After hiring people, act as if they are trying to damage the franchise on a daily basis, give them very little responsibility, remind everyone the place only runs because of the boss's efforts and genius. Give juniors no path for monetary or career advancement.

Best: what it takes to do a great job. Level of detail, thought before action; how to have a productive debate.

Worst: some people will put all their effort into the performance of working but never actually work. You risk your own job calling it out because their speciality is hiding their incompetence.

Don't base your identity on your job. You are a person with a job, you are not your job.

As an overall observation, the happiest colleagues I've had have been the ones who are good at their jobs and care about producing good results, but also know when to let go, and to decouple their jobs from their personal lives. They were on time, did their jobs well, were good colleagues and always helpful.

Clock in, do good work and be proud of it, clock out.

Some people want to go for the high risk/high reward 70-hour week stressfest, and they always seem to be worse off for it, to try and be in that 0.1% who succeed in the struggle. That's their choice, but it comes at a too high cost.

Best: ignore your corporate overloads and do what's interesting, but do it well enough the overloads can't really be upset.

Worst: two here...

If something's hard to understand, it's probably just done poorly.

You may outpace others. Just help them as you can.

The best and worst both taught me to be kind, just... From different directions.

It’s not what they told me. It’s what I learnt while interacting with them.

Best colleague: Talk openly. Engage in discussions. Conversation about conflicts and criticism is good.

Worst colleague: Don’t engage. Shitty people are just shitty people.

Best: if it's complicated, it's wrong.

Worst: almost no business deliverable is one tenth as important as the people telling you to give up your time, strength and sanity in order to achieve it will tell you that it is.

Hell is other people.

Heaven is other people.

From the worst: "Bad people are bad for your brain. Get them away or get away from them"

From the best: "Ambition is the will to try what others won't."

Worst: you may very well have better ideas about how things should work based on your last job, but take your time to build credibility and internalize how things work at your current job before you start to push them.

Best: always be curious. When you spot a bad idea, be especially curious about the parts that will go wrong. Most of the time, people will figure it out and change course without a conflict.

Best: never start implementing something if you don't know how it solves the problem or why its needed

Its very common for people to come to you with a suggested solution rather than telling you their problem.

Can't count how many times I've been assigned to build feature X, and upon further digging realized it will not solve the requester's problem or won't do what they think it will.

worst: I have in two companies before being exposed to "Toxic Culture". Before working in my 3rd company, I didn't imagine that there are "engineers" who would go behind my back and just talk sh*t about the whole team. I left after few months, but to this day, I still couldn't process it. Culture does matter.

Worst colleagues? Don't work with them, however you can arrange that.

Life is too short. Or, to put it another way, life is too long.

* I wouldn't task someone with something I wasn't willing to do myself

* If you screw up, acknowledge it without passing the buck, take responsibility for it (works best if you have already worked out a mitigation strategy and timeframe to implement and can communicate this effectively)

Trust no one.

Best: “be an egoless programmer”. My boss taught me not to get defensive about my mistakes. It’s just code, and mistakes are normal.

Worst: a programmer with a huge ego. He was extraordinarily defensive about his work and this made the whole team unproductive.

I've actually collected a list of those bad ones over the years on my blog: http://nywkap.com/other/miserable-teams.html

Best: Trust yourself. You often can do something you think is beyond your ability if you're willing to try. But also it's OK to fail. Failure is a single event, not the end, and you can try again using what you learned.

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.

From the worst: always shower and stay up-to-date.

From the best: abstract only when needed.

To do what they do (from the best ones). To do the opposite (from the worst ones). From both, I learned to focus on what I want, in order to discern the the above

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.

If you were placed in a situation where everything feels like it’s on fire and falling apart, don’t go complaining to your manager. There’s a good chance your leader ship already knows, and that’s exactly why they put you there. Because they trust you to get things back on track. But this isn’t necessarily great for your mental health. So you have to prioritize and strike a balance on what matters and what doesn’t. Don’t let small things get to you.

Best: Office politics is more about perception of doing work and less about actually doing work.

Worst: Apparently knowing how to use excel efficiently isn't better because manual calculations prevent errors.