Ask HN: What lessons did you learn from your best or worst colleagues?
I have a theory that you learn lessons from all your colleagues--best, worst, and everything in between. Interested to hear what lessons you feel are worth sharing.
269 コメント
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: delivering high-quality work quickly matters
Worst: but it's amazing how long a person can last without doing much at all!
Worst: but it's amazing how long a person can last without doing much at all!
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.
Worst: Apparently knowing how to use excel efficiently isn't better because manual calculations prevent errors.
the damage from 1 excel error can be so risky that its better for the company to pay a person to do the entire thing manually and derisk. infuriating from the perspective of technics, but not from that of incerto
Doing calculations manually is orders of magnitude more likely to introduce errors.
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.
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.
Trust no one.
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.
Worst: Stay in your lane.
However, if you set up meetings in a way that decisions can be made (i.e. prepare a design document with several options and make the meeting about choosing which one) you will find that meetings can be very productive.
In general, decisions that actually stick--where multiple points of view are explored in real time--only get made in meetings. Announcing a decision in an email without a conversation rarely works out well unless there has been a thorough discussion with those affected and those who may have relevant knowledge or expertise.
Decisions get agreed upon in meetings.
The actual decisions have been made in the days, weeks, sometimes months leading up to the meeting. And the amount of human input going into them can vary from very little to gargantuan.
I believe there is even a saying that before an important meeting takes place the people required to attend it will hold one or more unofficial meetings to make up their minds about the topics on the important agenda.
The actual decisions have been made in the days, weeks, sometimes months leading up to the meeting. And the amount of human input going into them can vary from very little to gargantuan.
I believe there is even a saying that before an important meeting takes place the people required to attend it will hold one or more unofficial meetings to make up their minds about the topics on the important agenda.
I find the definition of a decision as "the irrevocable commitment of resources" to be very useful. Plans may be made in advance of a meeting but until resources are committed and behavior/processes changes there may be a pronouncement but no decision.
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.
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.
Best: be competent, be kind, collaborate
Worst: be competent, be rude, don't collaborate
Worst: be competent, be rude, don't collaborate
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.
Worst: Don't tell employees you pay them so they shouldn't have to use Google.
Heh. I think the joke is that my company pays me 1 dollar a week to do Google searches, and 2000 dollars week to know which of the 100,000 results is worth following.
For those new to the joke: https://www.snopes.com/fact-check/know-where-man/
The same goes for knowing when to pay attention to Stack Overflow or GitHub and when not to. ;-)
In fact, it would probably be funnier if it were $1 to implement a new feature with an npm package and $1999 for knowing which npm package to use.
That said, usually when I search HN and stick to recent posts/comments within the last year, the advice often proves useful to some degree, as when experts share their direct experiences. For less technical concerns the same can be true of Reddit.
The same goes for knowing when to pay attention to Stack Overflow or GitHub and when not to. ;-)
In fact, it would probably be funnier if it were $1 to implement a new feature with an npm package and $1999 for knowing which npm package to use.
That said, usually when I search HN and stick to recent posts/comments within the last year, the advice often proves useful to some degree, as when experts share their direct experiences. For less technical concerns the same can be true of Reddit.
That is basically a truth.
If you sit in IT people bubble then you might feel ashamed that you have to look up stuff all the time.
But technicians always had books like "mechanics guide" or "lookup tables" and they mostly knew which things to apply and where. Without training and experience you don't even know what to look for.
IT bubble people overestimate non IT people level of understanding, I see how "normal" people still struggle with basic text editing or using browser features that are obvious to me like "open link in a new tab". I am not talking here about my grandmother but even people in their 20's but just those non IT.
If you sit in IT people bubble then you might feel ashamed that you have to look up stuff all the time.
But technicians always had books like "mechanics guide" or "lookup tables" and they mostly knew which things to apply and where. Without training and experience you don't even know what to look for.
IT bubble people overestimate non IT people level of understanding, I see how "normal" people still struggle with basic text editing or using browser features that are obvious to me like "open link in a new tab". I am not talking here about my grandmother but even people in their 20's but just those non IT.
I took my semi truck to one of the company shops recently. There were some electrical problems that were getting progressively worse.
The technician thought, poked, checked, asked a colleague.
Finally he got out his phone, googled, and disconnected the batteries for about ten minutes. Then reconnected the batteries, and all was well.
I guess something needed to be put to death and reincarnated.
He laughed about it and told me how he fixed it. I laughed too and thanks him, but sometimes that's what you do, and you have to know enough to select the likely or possible out from the unlikely and implausible.
The technician thought, poked, checked, asked a colleague.
Finally he got out his phone, googled, and disconnected the batteries for about ten minutes. Then reconnected the batteries, and all was well.
I guess something needed to be put to death and reincarnated.
He laughed about it and told me how he fixed it. I laughed too and thanks him, but sometimes that's what you do, and you have to know enough to select the likely or possible out from the unlikely and implausible.
[deleted]
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.
Worst: Good people can sometimes land in the wrong role. Change conditions before passing judgement.
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.
Needed to read this, thanks.
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.
Worst: some workplaces allow the negative workers on the team to get away with anything.
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.
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.
Name checks out. But, great comment and I will remember allies build careers. I’ve started to realize this. Trust is important.
> Bad people often don’t have bad careers, and there is no justice
I always like to think that “the arc of the moral universe is long but it bends towards justice.” Not all of them, but many of the bad folks you work with eventually flame out or stall.
The rest seem to become CEOs.
I always like to think that “the arc of the moral universe is long but it bends towards justice.” Not all of them, but many of the bad folks you work with eventually flame out or stall.
The rest seem to become CEOs.
> being right a lot
well if you are "right a lot" then it's easy to reap "better dividends".
it's easy to get promoted, just never introduce bugs and always know the solution to all problems and deliver it before yesterday!
well if you are "right a lot" then it's easy to reap "better dividends".
it's easy to get promoted, just never introduce bugs and always know the solution to all problems and deliver it before yesterday!
> This builds allies and allies build careers.
Compliment people behind their back relentlessly.
Compliment people behind their back relentlessly.
Best: tactical diplomacy can be learned and is very valuable
Worst: The people who talk about others will talk about you
Worst: The people who talk about others will talk about you
What are some examples/situation where the tactical diplomacy can be applied and is useful?
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.
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.
I’m always amazed by how irrelevant the objectives produced by business planning processes can be. It’s so common to hear things like, “yes, we know this won’t ever end up in a product, but it’s in our objectives, so we have to focus on it”. The task was leviathan and impossibly complex, so it doesn’t get accomplished, and then every quarter the goals focus on a smaller piece of this until the group delivers some result, which is celebrated internally but now obviously irrelevant to the business, so everybody gets laid off, except the people that set the objectives in the first place. Yeah, you can easily pour your life into something that is completely meaningless, even to the company that is paying you to do it.
I wonder why this post was downvoted? I have the same experience for 25+ years of development experience.
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.
Worst: Fire them all really really quickly. People that are bad after week 2-4 will never not be bad afterwards.
I would say it depends on attitude, if someone is saying he wants to learn, then he is just saying. If someone is struggling but is interested and doing stuff to learn more he still might pull out of downside.
If they have an excellent attitude I'd definitely give them a lot of time to prove themselves.
These are very true. However, if you have to fire someone right away, it’s usually because you didn’t tell them something, especially that you fire quickly, and common reasons why. You as the employer have all the power of discovery, not them.
The simplest thing to do is show the candidate exactly what they are going to do. Don’t describe it, actually show the code base and the devops setup and the meeting schedule and the reports that go out and the planning documents and knowledge base and whatever else they’ll need to engage with. Tell them their exact goal for the first year, and exactly what they get if they achieve it.
In other terms, give them the SOP, OPORD, and pre-flight checklists before they reassign. What is obvious to you is not to them.
The simplest thing to do is show the candidate exactly what they are going to do. Don’t describe it, actually show the code base and the devops setup and the meeting schedule and the reports that go out and the planning documents and knowledge base and whatever else they’ll need to engage with. Tell them their exact goal for the first year, and exactly what they get if they achieve it.
In other terms, give them the SOP, OPORD, and pre-flight checklists before they reassign. What is obvious to you is not to them.
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.
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.
Hell is other people.
Heaven is other people.
Heaven is other people.
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.
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 way to do software.
Quotations mean beliefs of person having such of a approach.
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 way to do software.
Quotations mean beliefs of person having such of a approach.
> 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.
> [ . . . ]
> Quotations mean beliefs of person having such of a approach.
You can learn how not to do something from observing someone doing things wrong.
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.
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.
> 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.
I try to always have this kind of mindset, but sometimes I just don't see how to do it. Imagine you are at the office, the break room's microwave just broke down and you are discussing with your colleagues what should you ask at management to replace it. Two units ? Since the company grew and one microwave for twenty people is not enough. One more powerful ? The old one took like ten minutes to heat even the smallest meal. And then a colleagues, very seriously, suggest that a big barbecue would be more efficient and can heat many meals at a time. If we take the physical constraints (buying a barbecue...) apart since in software we can easily let a bad project dies in the limb of our repository, how can you say "okay, we’ll try it out and see what happens" to them ?
I try to always have this kind of mindset, but sometimes I just don't see how to do it. Imagine you are at the office, the break room's microwave just broke down and you are discussing with your colleagues what should you ask at management to replace it. Two units ? Since the company grew and one microwave for twenty people is not enough. One more powerful ? The old one took like ten minutes to heat even the smallest meal. And then a colleagues, very seriously, suggest that a big barbecue would be more efficient and can heat many meals at a time. If we take the physical constraints (buying a barbecue...) apart since in software we can easily let a bad project dies in the limb of our repository, how can you say "okay, we’ll try it out and see what happens" to them ?
You can at least entertain the idea, bad ideas spin themselves apart at the planning stage.
"I have a mobile smal bbq kit at home. I could bring that in for a try tomorrow. But were do we bbq. Fire detectors go off inside the building, so should be outside. Will bring it, but i wont grill out there in the rain, im for a rotating job on that. Volunteers?" There - death by self-execution. And you didnt even murder it by pulling hierarchy, which is always a good way to create a contribution dead company, were everyone just waits for the clock to go forward.
There is more to managing then making decisions (like in the movies). And in reality it should be more of a supportive role. And yes, sometimes you must entertain doomed ideas (like flying bicycles - those wright brothers, i kid you not).
"I have a mobile smal bbq kit at home. I could bring that in for a try tomorrow. But were do we bbq. Fire detectors go off inside the building, so should be outside. Will bring it, but i wont grill out there in the rain, im for a rotating job on that. Volunteers?" There - death by self-execution. And you didnt even murder it by pulling hierarchy, which is always a good way to create a contribution dead company, were everyone just waits for the clock to go forward.
There is more to managing then making decisions (like in the movies). And in reality it should be more of a supportive role. And yes, sometimes you must entertain doomed ideas (like flying bicycles - those wright brothers, i kid you not).
> Will bring it
What if they say yes, and then you spend time bringing the bbq equipment to the workplace (although you didn't want to) and then your manager wonders "what are you doing, this'll set of the fire alarm", and you say "the others wanted to try this"
What if they say yes, and then you spend time bringing the bbq equipment to the workplace (although you didn't want to) and then your manager wonders "what are you doing, this'll set of the fire alarm", and you say "the others wanted to try this"
Provide the context - nicely, of course. If the manager is worth their salt they'll get it, all the way to the point that the BBQ is a team building exercise.
If said boss gets it immediately, I would like to know if he's hiring. ;P
If said boss gets it immediately, I would like to know if he's hiring. ;P
Take 5 min to run it by your manager. "The microwave is broken so we want to being a portable grill to make lunch with Tomorrow."
If your manager has objections that's evidence it was a bad idea.
Maybe it becomes a company tradition instead to have a hill day instead though?
If your manager has objections that's evidence it was a bad idea.
Maybe it becomes a company tradition instead to have a hill day instead though?
Thank you. I'll try to keep that in mind next time I'm in this kind of situation and see how it turns out.
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 team will support the idea. 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.
It’s the same thing with code reviews. I make a distinction between issues of opinion vs issues of correctness. I will never let incorrect code get checked in, but if it’s a matter of opinion, then I’m more lenient to let things in.
It’s the same thing with code reviews. I make a distinction between issues of opinion vs issues of correctness. I will never let incorrect code get checked in, but if it’s a matter of opinion, then I’m more lenient to let things in.
> 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 ?
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 ?
I see exactly what you are saying about CR. And that's exactly my mindset. But sometimes people argue that it's a matter of opinion while to me it's a matter of correctness. In those cases I'm lost because on one hand I deeply know that they are wrong, but on the other hand I don't want to be the bad guy that always reject PR because I think my opinion is more important than their.
TL;DR : I don't know where to draw the line between people's limits and my own stupidity.
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 ?
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 ?
I see exactly what you are saying about CR. And that's exactly my mindset. But sometimes people argue that it's a matter of opinion while to me it's a matter of correctness. In those cases I'm lost because on one hand I deeply know that they are wrong, but on the other hand I don't want to be the bad guy that always reject PR because I think my opinion is more important than their.
TL;DR : I don't know where to draw the line between people's limits and my own stupidity.
> 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
That’s called “The Abilene Paradox.”[0]
[0] https://en.m.wikipedia.org/wiki/Abilene_paradox
>It’s the same thing with code reviews. I make a distinction between issues of opinion vs issues of correctness.
Good way of putting it. Too often code reviews devolve into nit-picking and bickering.
Good way of putting it. Too often code reviews devolve into nit-picking and bickering.
I actually agree with this. Although I try to give the people I supervise as much freedom to come up with ideas and solutions as possible, there are some that almost always come up with outrageous ideas that will never work or they overestimate their own skills and over promise. I think that it is my responsibility to tell them that their ideas are not going to work and that's not a good idea to pursue them. It will only lead to disappointments and wasted time in the end.
That said, some of the people I manage are clearly better at dealing with the freedom to come up with solutions than others. I feel like it's often the same people over and over again that try to install barbecues everywhere. I tend to give some colleges more freedom than others, because I know from previous events (i.e. I have a bias towards them) that their ideas might not be so crazy as I think they are. But I tend to stop other colleges, that have tried to install barbecues in the office several times in the past, when they come up with ideas that I think are probably not going to work.
That said, some of the people I manage are clearly better at dealing with the freedom to come up with solutions than others. I feel like it's often the same people over and over again that try to install barbecues everywhere. I tend to give some colleges more freedom than others, because I know from previous events (i.e. I have a bias towards them) that their ideas might not be so crazy as I think they are. But I tend to stop other colleges, that have tried to install barbecues in the office several times in the past, when they come up with ideas that I think are probably not going to work.
> There really isn’t much to learn from scumbags since it’s obvious you shouldn’t be a scumbag.
You can learn how to recognize them faster, or how to work with them despite their behavior, or practice standing up for yourself, etc.
You can learn how to recognize them faster, or how to work with them despite their behavior, or practice standing up for yourself, etc.
>One of my mentors at the first company I worked for in Silicon Valley never said “no” to one of my ideas
This is key to mentorship and building an actual team. Junior Engineers need help in building their Self-Confidence and grow into Leadership positions and this is the way to do it.
Note that asking you to come up with ideas and entertaining them does not automatically mean accepting it.
This is key to mentorship and building an actual team. Junior Engineers need help in building their Self-Confidence and grow into Leadership positions and this is the way to do it.
Note that asking you to come up with ideas and entertaining them does not automatically mean accepting it.
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.
Worst: Letting toxic people get away with insults because they're good at their job.
> Worst: Letting toxic people get away with insults because they're good at their job.
Okay, that's what happened, but what did you learn from it? Presumably you're not always their boss and in a position to single-handedly do something about it. How should one deal with it instead? Or was the lesson about recognizing the situation?
Okay, that's what happened, but what did you learn from it? Presumably you're not always their boss and in a position to single-handedly do something about it. How should one deal with it instead? Or was the lesson about recognizing the situation?
[deleted]
The best and worst both taught me to be kind, just... From different directions.
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: 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.
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.
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.
Clearly he's got some issues given the reaction. However, was he informed of the bug? Was there an expectation he would fix his own mistakes?
I don't work in IT/Software Engineering - I work in law. But when I find fault in other's work, it's a courtesy to let them know and give them an opportunity to address it. It's part of being a team player. I am not trying to be critical of you. It's just reading this reminded me of similar experiences where I was in a similar position to you. They were important experiences. People can feel bad when other people fix their mistakes when they aren't given the opportunity to be heard about it. It's so tempting to just say 'I will just do it myself' but you might find other people react poorly to this.
Of course, maybe things are different in the IT world where it may be challenging to identify who committed a buggy change to the code repository, or perhaps just a radically different culture of work. But at the end of the day we are all human.
It does appear you have developed an awareness of this, given what you noted in your reply to him (and props to you for that!). From there on, his behaviour was misguided and not appropriate.
I don't work in IT/Software Engineering - I work in law. But when I find fault in other's work, it's a courtesy to let them know and give them an opportunity to address it. It's part of being a team player. I am not trying to be critical of you. It's just reading this reminded me of similar experiences where I was in a similar position to you. They were important experiences. People can feel bad when other people fix their mistakes when they aren't given the opportunity to be heard about it. It's so tempting to just say 'I will just do it myself' but you might find other people react poorly to this.
Of course, maybe things are different in the IT world where it may be challenging to identify who committed a buggy change to the code repository, or perhaps just a radically different culture of work. But at the end of the day we are all human.
It does appear you have developed an awareness of this, given what you noted in your reply to him (and props to you for that!). From there on, his behaviour was misguided and not appropriate.
Not the original poster but I think things are just radically different by the sounds of it. Every company I have worked at, once the code is in the main revision everyone is responsible for it. At that stage the code has gone through many people from reviewers to testers, its not one single persons fault.
Easiest thing to do ia not to blame but to just find a solution and see as a team if it was a genuine mistake that is unavoidable or if you can make some adjustment to the process to ensure quality and reliability of your code.
People can specialise in a certain area of the codebase but no one 'owns' anything. Everyone needs to respect that any change to the code is a neccesary one. The 'expert' or original coder is usually a reviewer of the changes proposed anyway so thats when they can voice opinion on whether someone has misunderstood something or not.
Bugs/Features can be worked on by anyone without ego getting in the way.
Easiest thing to do ia not to blame but to just find a solution and see as a team if it was a genuine mistake that is unavoidable or if you can make some adjustment to the process to ensure quality and reliability of your code.
People can specialise in a certain area of the codebase but no one 'owns' anything. Everyone needs to respect that any change to the code is a neccesary one. The 'expert' or original coder is usually a reviewer of the changes proposed anyway so thats when they can voice opinion on whether someone has misunderstood something or not.
Bugs/Features can be worked on by anyone without ego getting in the way.
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.
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 in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.
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 in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.
This sounds like a leadership issue.
I personally would either point it out or actually leave the project.
We don't have to accept every shitty job as Software engineers.
Unfortunately it takes time to experience and see those issues and to learn to handle them properly.
I do prefer sustainable development and at least my track record shows that it is paying off: high security, high trust in the system, stress-free oncall etc.
If I can't sit in a beer garden on a nice august afternoon a little bit early because everything is falling in peaces I have done something wrong. Not saying that I'm spending all my time not working just saying to have the freedom to be more flexible in when and how I work.
This does demand pushback to management if someone outside of your team starts to sell things with deadlines without asking you.
I personally would either point it out or actually leave the project.
We don't have to accept every shitty job as Software engineers.
Unfortunately it takes time to experience and see those issues and to learn to handle them properly.
I do prefer sustainable development and at least my track record shows that it is paying off: high security, high trust in the system, stress-free oncall etc.
If I can't sit in a beer garden on a nice august afternoon a little bit early because everything is falling in peaces I have done something wrong. Not saying that I'm spending all my time not working just saying to have the freedom to be more flexible in when and how I work.
This does demand pushback to management if someone outside of your team starts to sell things with deadlines without asking you.
Very interesting stuff to read from the perspective of an unenlightened outsider.
This works up util a point.
If the code is owned by 4-30 people, its good.
If the code is owned by 120 people, then it takes way to long to tell what the quality standard is.
> The standard you scroll past is the standard you accept.
The challenge is how to get work done without spending 60 hours a week pointing out or solving code quality problems. To overcome this challenge requires accepting some standard of crappy code.
If the code is owned by 4-30 people, its good.
If the code is owned by 120 people, then it takes way to long to tell what the quality standard is.
> The standard you scroll past is the standard you accept.
The challenge is how to get work done without spending 60 hours a week pointing out or solving code quality problems. To overcome this challenge requires accepting some standard of crappy code.
I think it is worth it in the lo g run.
In best case your team grows and the original hurdles are fixed.
It's always problematic for bad colleges which just do the same mistakes over and over and over again but what do you wanna do? Accept a potential security bug because it is too much effort?
If your code is so complex or big that you have 120 people on it, you should have enough people in governance positions and hierarchical quality gates.
In best case your team grows and the original hurdles are fixed.
It's always problematic for bad colleges which just do the same mistakes over and over and over again but what do you wanna do? Accept a potential security bug because it is too much effort?
If your code is so complex or big that you have 120 people on it, you should have enough people in governance positions and hierarchical quality gates.
> what do you wanna do? Accept a potential security bug because it is too much effort?
Yes. It is important to have the serenity to accept the things you cannot change.
In the choice between
A. Burning out on a fool’s errand of attempting to fix/prevent all the security bugs.
B. Giving up as you accept that people write security security bugs and as an individual contributor you have insufficient power to stop all of them.
C. Accepting the existence of bugs all around you and focusing on changing the small bits of code that you can.
The latter is preferable.
Yes. It is important to have the serenity to accept the things you cannot change.
In the choice between
A. Burning out on a fool’s errand of attempting to fix/prevent all the security bugs.
B. Giving up as you accept that people write security security bugs and as an individual contributor you have insufficient power to stop all of them.
C. Accepting the existence of bugs all around you and focusing on changing the small bits of code that you can.
The latter is preferable.
No offense taken. Your questions are valid.
1. Would he be informed of the/a bug(s)? Absolutely. We monitor bug tickets submitted to our team throughout the day. It's a main part of our job.
2. Was there a strict code ownership per individual contributor? No. This team's culture was such that once one contributor's code was committed to the main repository, it is part of the team's responsibility, not just the original contributor. In fact, any kind of don't-touch-my-code attitude was heavily frowned upon, worthy of a warning. I understand other teams may have different cultures.
I was too young to know the office dynamics back then, but in hindsight from more life experiences since then, I now see that he was just a very insecure person. His former colleagues were advancing ahead of him, making 4x his salary, and the last thing he wanted was a young team member outperforming him. This observation itself is a life lesson for me.
1. Would he be informed of the/a bug(s)? Absolutely. We monitor bug tickets submitted to our team throughout the day. It's a main part of our job.
2. Was there a strict code ownership per individual contributor? No. This team's culture was such that once one contributor's code was committed to the main repository, it is part of the team's responsibility, not just the original contributor. In fact, any kind of don't-touch-my-code attitude was heavily frowned upon, worthy of a warning. I understand other teams may have different cultures.
I was too young to know the office dynamics back then, but in hindsight from more life experiences since then, I now see that he was just a very insecure person. His former colleagues were advancing ahead of him, making 4x his salary, and the last thing he wanted was a young team member outperforming him. This observation itself is a life lesson for me.
Thanks for following up.
Because I wanted to ask why he would be so mean to you. That insecurity part answers that.
Because I wanted to ask why he would be so mean to you. That insecurity part answers that.
I understand the insecurity part, I don’t understand the behavior. Or maybe I do, I just consider the person an asshole first, and insecure second.
I don’t enjoy being corrected by my team members either, but that’s more out of frustration that I did something wrong in the first place.
The act of correction may be annoying at times, but you absolutely shouldn’t punish the initiative.
I don’t enjoy being corrected by my team members either, but that’s more out of frustration that I did something wrong in the first place.
The act of correction may be annoying at times, but you absolutely shouldn’t punish the initiative.
One point though: i personally don't like that as well as I see my bugs/issues as something I should fix.
I always prefer a short message like 'hey I saw a bug here and I will fix it. At least this gives me a heads-up.
But of course I wouldn't tell you that and I would definitely not hold a grudge against you because of it.
I always prefer a short message like 'hey I saw a bug here and I will fix it. At least this gives me a heads-up.
But of course I wouldn't tell you that and I would definitely not hold a grudge against you because of it.
Software is a machine. You don't ask the other mechanics if you can go and replace a faulty part on an engine they rebuilt last week. The engine is broken, you fix it and move on.
I would still expect communication. After all I don't want someone else to take away a potential learning experience.
If someone else just fixes stuff for you all the time that just might not be good in the long run.
If someone else just fixes stuff for you all the time that just might not be good in the long run.
The bosses behavior is the worst I’ve ever seen.
Sure, if there is time, it is best to file a ticket and notify the code writer so he can fix his own bug. That’s how he learns, but an urgent bug?
The worst part is his reaction. He literally twisted the person’s words to the worst interpretation possible.
What a piece of shit colleague.
Sure, if there is time, it is best to file a ticket and notify the code writer so he can fix his own bug. That’s how he learns, but an urgent bug?
The worst part is his reaction. He literally twisted the person’s words to the worst interpretation possible.
What a piece of shit colleague.
I feel like most people wouldn’t need this kind of bad lesson to know what not to do. And those who would are a lost cause anyway, as they probably know that what they’re doing is wrong.
Does this company use any form of stack ranking to determine bonuses?
It sounds like one possibility is your boss may have been trying to prevent you from getting to his level which would mean he would have to compete with you.
Stack ranking incentivizes people at higher levels to only allow incompetent people to get to their level because they’ll look better in comparison.
It sounds like one possibility is your boss may have been trying to prevent you from getting to his level which would mean he would have to compete with you.
Stack ranking incentivizes people at higher levels to only allow incompetent people to get to their level because they’ll look better in comparison.
Looks like he set you up to fail no matter what you would have said back then.
True, at best he was talking purely cynical and out of frustration. Still handled really very well by not adding any more vitriol but rather talking about the facts. Eventually the OP even got promoted.
> He always welcomed criticism of his work.
What are some ways to do this effectively?
What are some ways to do this effectively?
Personally, I try to detach it from myself and think in term of process, even if they are just internal processes (as in processes I created for myself).
Why was this bug not prevented? Did I follow the processes? If yes, why did they fail, and how can I change them not to fail next time? If not, why did I not follow them? How can I ensure that this will not happen again?
Also, can I share my experience? Can I learn from someone else experience? I think it's very good to say "I did this and that, which I thought would be enough, but it wasn't, how do you guys do it?".
Not saying it's perfect, and I always feel bad whenever there's a bug in code I wrote, but I'd rather hear about it, if only just to try to reduce the amount of time this happens in the future.
Why was this bug not prevented? Did I follow the processes? If yes, why did they fail, and how can I change them not to fail next time? If not, why did I not follow them? How can I ensure that this will not happen again?
Also, can I share my experience? Can I learn from someone else experience? I think it's very good to say "I did this and that, which I thought would be enough, but it wasn't, how do you guys do it?".
Not saying it's perfect, and I always feel bad whenever there's a bug in code I wrote, but I'd rather hear about it, if only just to try to reduce the amount of time this happens in the future.
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.
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.
Just listen and try to steel man what they are saying as best you can before you start to consider how it might be wrong.
Try to get onto the path of thought that led them there, but let the questions that arise naturally for you hold off as long as you can.
To be clear this is like a policy, you will fail at it but it reminds you of the prinicals that you believe in.
I learn a lot doing this in more ways than i could explain in a book, never mind a comment.
Try to get onto the path of thought that led them there, but let the questions that arise naturally for you hold off as long as you can.
To be clear this is like a policy, you will fail at it but it reminds you of the prinicals that you believe in.
I learn a lot doing this in more ways than i could explain in a book, never mind a comment.
doesnt matter how wrong or personally based the attack/criticism is. The more extreme the situation the more important it is to keep to the plan.
the lessons learned will cover all of existance as you will learn more about how people model the world, problems and solutions beyond the specifics of the problem at hand.
*if doing this drains you make a change of environment (e.g. job), however i find that the discussions you have like this change other peoples thinking more effectively, so its also how you sew the seeds of cultural change.
the lessons learned will cover all of existance as you will learn more about how people model the world, problems and solutions beyond the specifics of the problem at hand.
*if doing this drains you make a change of environment (e.g. job), however i find that the discussions you have like this change other peoples thinking more effectively, so its also how you sew the seeds of cultural change.
You can see from the other comments that people like prescriptive actions that anybody can take. It's a lot harder to accept that you might have some behavioral or mental issues that you need to dig into which would then make all of these behaviors natural. Forcing yourself to be a steel man is pretending. Becoming a steel man is much harder but is possible for those who willingly seek treatment. If you're willing to ask this question it means you are a good candidate for treatment. Good luck.
I like to think of criticism as scientific peer review. The purpose of that is not to criticise the person, but to strengthen the validity of their research by eliminating any remaining errors they may have missed.
Your peers aren't harming you by finding fault, they're strengthening your position by doing so.
I personally hate it when a bug slips through to production, and I always profusely thank anyone that spots one before it does. Or after. Whatever, as long as it gets fixed...
Your peers aren't harming you by finding fault, they're strengthening your position by doing so.
I personally hate it when a bug slips through to production, and I always profusely thank anyone that spots one before it does. Or after. Whatever, as long as it gets fixed...
Similar to people with ptsd, your amygdala may be overactive. You can try different methods of reducing your general level of stress.
How do you not immediately report this guy to HR? His behavior is absolutely verbal abuse.
Please don't play it emotionally and report it to HR. Folks from HR are there to take care of the manager and employer. Such a step could be suicidal.
Maybe this is different here in Europe, but HR's role is to protect the company. HR in my experience does not do whatever a manager wants. Let's say you have a toxic direct, unless you have a 50 page document outlining every single transgression or bad behavior and the steps you took to mediate said behaviour, including corrective feedback, and statements by the toxic employee's peers supporting your observations, HR will often times do exactly nothing and happily ignore you, and even then, they could still propose "mediation" or "conflict resolution" procedures because they are afraid of an unfair dismissal law suit or whatever.
I find this attitude to be the same as kids not telling on the bully because it’ll make things worse. The guy lost a four figure bonus for no sane reason. Keeping quiet isn’t going to make anything better. You either speak with HR or firstly maybe your boss’s boss. Maybe things are a bit different if you work in one of the places where you can be fired at will but generally you have employment rights that will protect you.
Never talk to the bosses boss without going to your boss first. By doing so, you are ignoring the chain of command and likely will you fired. How would you feel if someone you managed went behind your back to talk to your boss?
That kind of behavior is for me a red flag which would definitely lead to me scheduling a meeting with the boss of my boss.
If you really wanted to stay with that company because everything else is great, your only chance is to solve this with the boss of the boss.
5 figure bonus lost due to this is abuse.
If you really wanted to stay with that company because everything else is great, your only chance is to solve this with the boss of the boss.
5 figure bonus lost due to this is abuse.
Agreed, I thought that was implied in my comment but reading back it isn’t.
I disagree that going above your boss first would lead to getting fired though (again with the exception of at will employment).
I disagree that going above your boss first would lead to getting fired though (again with the exception of at will employment).
That is such a bullshit meme that needs to die.
HR's exact goals vary between companies, but unless the company culture is toxic all the way to the top, part of their job is usually to reduce staff turnover (which is very expensive for the company), and in pretty much any company their job is to protect the company against lawsuits. Abusive managers are not well liked by HR.
HR's exact goals vary between companies, but unless the company culture is toxic all the way to the top, part of their job is usually to reduce staff turnover (which is very expensive for the company), and in pretty much any company their job is to protect the company against lawsuits. Abusive managers are not well liked by HR.
That doesn't align with my experience. In my experience, they pretend to care about the employee, but when the employer is in the wrong, even in an obvious way, they will side with the employer in the blink of an eye every time instead of trying to reason with the employer.
The abusive boss is just an employee too
The employer, yes. Some low-level manager? Not at all. It is not in the employer's interest to take the side of a toxic manager who may cause several of their reports to quit.
Just as you have to earn the respect from everyone, each single individual in that org must earn your respect. Choose your confidants carefully. HR is for door in, and out.
HR doesn’t work for you.
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.
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.
Thanks a lot for your comment. There's a lot in there. In fact, I added most of it to my personal collection of quotes.
> To change anything you have to be responsible, empowered, and knowledgeable about it.
What do you mean by those that?
What do you mean by those that?
So I'm actually planning on writing a blog post on it which at some point I'll share, but, basically -
Responsible: You're the one affected by something, and the one expected to respond to it (first, possibly only). You have incentive to prioritize it highly and deal with it. I.e., if anyone cares about it, it's you. So, for instance, an alert goes off that a service is down. While it may affect the whole company, if it's your service, -you- are responsible for it. "We're all responsible for it" is not true; who feels that sense of ownership, who is going to have to write the post-mortem, who would be blamed if it's a blame culture, etc. Or, more succinctly for this example, "who is waking up to deal with it". This matters because it's too easy to blur lines of responsibility; is the director of the department responsible for it? No; while long down time that leads to revenue loss may require his presence in meetings and things, he isn't expected to actually go fix it himself. He's responsible for hiring the right people, and setting the right policies in place; NOT answering the Pagerduty. Broadly sharing responsibility is an anti-pattern, and, frankly, a lie; it's why "decision by committee" and "too many cooks in the kitchen" are bad ideas.
Empowerment: The changes you need to make, you can make. This might be in terms of organizational authority, or actual technical permissions. In the prior example, if I can't access prod enough to fix the issue, I'm not empowered. What I AM empowered, and responsible, to do, is send emails/call someone who can make the changes. If I don't know who that is, I'm not knowledgeable; I can do what I -am- knowledgeable of (send an email to the whole department? Post it in a seemingly relevant Slack channel? File a ticket?), and then wipe my hands of it until I can either acquire new knowledge (who to reach out to), or new empowerment (the ability to make the changes).
Knowledgeable: Knowing what needs to be done. This might be a business need, or it might be technical. Technical is 'easy', in that you can usually go learn it on your own, but the business is harder, as it comes from somewhere that may not want to work with you, or that you can't identify. As an engineer, I might be responsible and empowered to build things, but I'm not knowledgeable about -what- the business wants/needs; I have to get that information from product or other stakeholders.
If I know what and how something should be done, I'm responsible for delivering it, and I'm empowered to actually go get it done, I can (and if a good employee, will) do it. If I'm missing any of those, I can't; I have to get the missing piece(s). This sounds obvious, and it kind of is, but pretty much every organizational problem I've run into can be framed using this (though sometimes with slightly hand-wavey definitions).
Dev is blocked on product; dev doesn't have the knowledge to know what to build. Go to product; they don't have the knowledge either. Further, they're not empowered to prioritize getting that knowledge; instead, they're spending all their time on what they feel responsible for, say, unrelated meetings, UX design, and documentation of status. A fix: change what product is responsible for (from "gather status and respond to upper management -> unblock dev"), and empower them to prioritize their time accordingly.
Dev feels releases are a pain in the ass; they are responsible, but empowerment to actually push to prod resides in an ops team. The ops team has the empowerment, and the knowledge, but they don't feel responsibility; if a release goes bad it's their issue, but if a release doesn't happen it's the dev team's issue. A fix: Either empower devs to release to prod without the ops team's involvement, or make ops feel responsible for releasing (i.e., time between dev says "we want this released", and when it gets released, is a factor on how the ops team's performance is evaluated).
Determining what is missing provides direction in what to address to solve the problem, and if you're unable to, moves it from something to agonize over, to something to accept as not something under your control.
Responsible: You're the one affected by something, and the one expected to respond to it (first, possibly only). You have incentive to prioritize it highly and deal with it. I.e., if anyone cares about it, it's you. So, for instance, an alert goes off that a service is down. While it may affect the whole company, if it's your service, -you- are responsible for it. "We're all responsible for it" is not true; who feels that sense of ownership, who is going to have to write the post-mortem, who would be blamed if it's a blame culture, etc. Or, more succinctly for this example, "who is waking up to deal with it". This matters because it's too easy to blur lines of responsibility; is the director of the department responsible for it? No; while long down time that leads to revenue loss may require his presence in meetings and things, he isn't expected to actually go fix it himself. He's responsible for hiring the right people, and setting the right policies in place; NOT answering the Pagerduty. Broadly sharing responsibility is an anti-pattern, and, frankly, a lie; it's why "decision by committee" and "too many cooks in the kitchen" are bad ideas.
Empowerment: The changes you need to make, you can make. This might be in terms of organizational authority, or actual technical permissions. In the prior example, if I can't access prod enough to fix the issue, I'm not empowered. What I AM empowered, and responsible, to do, is send emails/call someone who can make the changes. If I don't know who that is, I'm not knowledgeable; I can do what I -am- knowledgeable of (send an email to the whole department? Post it in a seemingly relevant Slack channel? File a ticket?), and then wipe my hands of it until I can either acquire new knowledge (who to reach out to), or new empowerment (the ability to make the changes).
Knowledgeable: Knowing what needs to be done. This might be a business need, or it might be technical. Technical is 'easy', in that you can usually go learn it on your own, but the business is harder, as it comes from somewhere that may not want to work with you, or that you can't identify. As an engineer, I might be responsible and empowered to build things, but I'm not knowledgeable about -what- the business wants/needs; I have to get that information from product or other stakeholders.
If I know what and how something should be done, I'm responsible for delivering it, and I'm empowered to actually go get it done, I can (and if a good employee, will) do it. If I'm missing any of those, I can't; I have to get the missing piece(s). This sounds obvious, and it kind of is, but pretty much every organizational problem I've run into can be framed using this (though sometimes with slightly hand-wavey definitions).
Dev is blocked on product; dev doesn't have the knowledge to know what to build. Go to product; they don't have the knowledge either. Further, they're not empowered to prioritize getting that knowledge; instead, they're spending all their time on what they feel responsible for, say, unrelated meetings, UX design, and documentation of status. A fix: change what product is responsible for (from "gather status and respond to upper management -> unblock dev"), and empower them to prioritize their time accordingly.
Dev feels releases are a pain in the ass; they are responsible, but empowerment to actually push to prod resides in an ops team. The ops team has the empowerment, and the knowledge, but they don't feel responsibility; if a release goes bad it's their issue, but if a release doesn't happen it's the dev team's issue. A fix: Either empower devs to release to prod without the ops team's involvement, or make ops feel responsible for releasing (i.e., time between dev says "we want this released", and when it gets released, is a factor on how the ops team's performance is evaluated).
Determining what is missing provides direction in what to address to solve the problem, and if you're unable to, moves it from something to agonize over, to something to accept as not something under your control.
This really stuck a cord, thank you for sharing.
+1 , some excellent points in there
* 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)
* 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)
learn the difference between colleagues/supervisors who are setting you up to succeed vs those who are waiting for you to fail and plan accordingly
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.
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.
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.
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.
Sarcasm comes out when a team is very healthy or very sick. It’s either a trust-fall game that brings everyone together or a way to ask a question without having it said in a low-trust environment. If you can’t tell if someone’s joking, that could mean they’re too scared to tell you the truth straight. Or, they trust you more than they should.
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.
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.
Vindication is morally questionable, but someone could be tempted to it to attach consequence to the offending behavior. After deciding not to take the low road, how did you handle these situations in the future?
That's a very good question. Since then, I have never had a coworker treat me in such a fashion, and so I cannot speak directly to it.
What I can do is express that the reflection of myself in that scenario was one I didn't like, and I've become quite a different person overall since then. My conflict resolution methods in general are much more constructive. When I have a problem with somebody I am calm but direct and tell them what the problem is. I used to mistake being blunt for being rude, but blunt (as long as it is kind, and not vicious) can be very effective.
What I can do is express that the reflection of myself in that scenario was one I didn't like, and I've become quite a different person overall since then. My conflict resolution methods in general are much more constructive. When I have a problem with somebody I am calm but direct and tell them what the problem is. I used to mistake being blunt for being rude, but blunt (as long as it is kind, and not vicious) can be very effective.
By "vindication" do you mean "revenge"? Because vindication is absolutely not questionable. Revenge may be questionable, but I find that not teaching bad people a lesson isn't much better.
Vindictive, which is the word I used (not vindication) is defined as followws:
"having or showing a strong or unreasoning desire for revenge."
So yes I was after revenge.
"having or showing a strong or unreasoning desire for revenge."
So yes I was after revenge.
I was replying to moosebear847, though I didn't notice you had said "vindictive", so I guess that's what they meant too, thanks!
It could have been worse. I was at college when I heard a previous bunch of students took vengeance on another student by replacing the magnetic disc in his 5 1/4" floppy with a circular disk sander.
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.
Bests: Hide your ambition the lazy will try to block you. The ambitious will try to remove you.
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 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.
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.
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.
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.
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.
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.
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.
This is anecdotal of course, but I've addressed people as Sir and have been addressed that way it's always in a friendly way. Usually it's just a sign of respect, you may think they're mocking you but they might just see you as one of the "old crew". It may even be a cultural thing, I've noticed that a lot of my Indian colleagues tend to use it as well. Anyway, when in doubt I'd just ask, otherwise next time someone does it just joke back that if they're calling you Sir, you should probably call them Mr. President, if the response is casual enough it's all good.
Thank you, you are right. Instead of being stressed about it, I should rather ignore it.
They are not mocking you. They respect you for making the right decision for the project as opposed to the best they could do, the right decission for themselves.
A sudden change in the tone is obviously noticeable. You can feel it when some one else is being called by their first name and you are being addressed as Sir.
That’s different then. I did call some people Sir but it was out of respect. Mostly I appreciated that they were easy to get along with.
If you did nothing wrong I would say it’s still a sign of respect even if done theatrically every time.
If you did nothing wrong I would say it’s still a sign of respect even if done theatrically every time.
Thank you. Noted. Your comment made me feel relaxed.
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
Best: they believe others are capable of achievement, and they offer help
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 colleague: Talk openly. Engage in discussions. Conversation about conflicts and criticism is good.
Worst colleague: Don’t engage. Shitty people are just shitty people.
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.
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.
I never understood this way of thinking about touch typing as a distinct skill from typing. My experience was that when you're kid and use a computer for the first time, you need to look at the keys, and then over time you look less and eventually you can type without looking at all. I never saw it as a distinct skill that needs it's own name or needs to be taught in school (apparently I'm wrong about this). It's just typing to me.
> I never understood this way of thinking about touch typing as a distinct skill from typing.
Touch typing is a special technique. Typing and touch typing being distinct things isn't a "way of thinking", it's a clear fact. It's not open to interpretation.
The keyboard is an instrument. Anyone can use it without learning the proper technique, but the technique helps a great deal. That's the whole point.
It is greatly comparable to musical instruments. For instance you can learn how to play the guitar yourself, but if you know the proper technique, you'll have better mastery in a shorter time. This is why it needs to be teached, especially to knowledge workers, who type, type and type all day long.
Maybe the skill you currently have is enough for you, but you shouldn't dismiss the proper technique, especially if you haven't tried it (you sound like you didn't really).
Though if you can answer yes to all the questions below, then you probably don't need the technique:
- Can you easily do 80+ wpm whether it is prose or code?
- Do you have more than 95% accuracy at all times?
- Do you never (no exceptions) look at the keyboard?
These things all make a difference. Having less friction with the input instrument results in a higher stamina in a knowledge worker, which means more productivity per unit of time. Few realize this.
Touch typing is a special technique. Typing and touch typing being distinct things isn't a "way of thinking", it's a clear fact. It's not open to interpretation.
The keyboard is an instrument. Anyone can use it without learning the proper technique, but the technique helps a great deal. That's the whole point.
It is greatly comparable to musical instruments. For instance you can learn how to play the guitar yourself, but if you know the proper technique, you'll have better mastery in a shorter time. This is why it needs to be teached, especially to knowledge workers, who type, type and type all day long.
Maybe the skill you currently have is enough for you, but you shouldn't dismiss the proper technique, especially if you haven't tried it (you sound like you didn't really).
Though if you can answer yes to all the questions below, then you probably don't need the technique:
- Can you easily do 80+ wpm whether it is prose or code?
- Do you have more than 95% accuracy at all times?
- Do you never (no exceptions) look at the keyboard?
These things all make a difference. Having less friction with the input instrument results in a higher stamina in a knowledge worker, which means more productivity per unit of time. Few realize this.
I could easily do 120 wpm at 98% accuracy before I switched to touch typing years ago. Now I'm at 80wpm at 95%.
You are the exception, you know that right? There will always be outliers. What we should care about is what the technique can do for the majority of the people.
But since you are an interesting exception, I'm curious of your take actually. Maybe please offer us some more information:
- Why do you think you did slow down after the switch to touch typing?
- Why did you feel the need to switch to touch typing if the skill you already had was so good?
- Do you think there are any benefits of touch typing over your old technique?
- Do you regret switching to touch typing? Why?
- How many years did it take you to get to 120 wpm at 98%?
- Is there anything you miss from your old technique (beside the higher stats)?
But since you are an interesting exception, I'm curious of your take actually. Maybe please offer us some more information:
- Why do you think you did slow down after the switch to touch typing?
- Why did you feel the need to switch to touch typing if the skill you already had was so good?
- Do you think there are any benefits of touch typing over your old technique?
- Do you regret switching to touch typing? Why?
- How many years did it take you to get to 120 wpm at 98%?
- Is there anything you miss from your old technique (beside the higher stats)?
> 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 after the switch to touch typing?
I have no idea, the way to hit the keys just feels less convenient to me. For example, the x and c are harder to hit because my fingers don't like going there, I can't really explain it better.
> - Why did you feel the need to switch to touch typing if the skill you already had was so good?
Half because I got an ortho split keyboard and couldn't use my old technique with it, and half because everyone said touch typing is so much better.
> - Do you regret switching to touch typing? Why?
Yes, my old technique is much more comfortable and faster. I still type the "old" way on regular keyboards, but it's not such a big deal either way, since I'm usually limited by the speed of my brain rather than my hands, and I don't much mind the reduced accuracy either. I'm touch typing this on the split keyboard right now.
> - How many years did it take you to get to 120 wpm at 98%?
I've been typing that way for 20 years, so I can't really say. I definitely remember being pretty good around 4 years in, possibly long before that.
> - Is there anything you miss from your old technique (beside the higher stats)?
It just feels more comfortable, when I touch-type I feel a bit like I'm fighting the keyboard, or as if I'm wearing shoes half a size too small. With my old technique (e.g. on my laptop) I feel at home.
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 after the switch to touch typing?
I have no idea, the way to hit the keys just feels less convenient to me. For example, the x and c are harder to hit because my fingers don't like going there, I can't really explain it better.
> - Why did you feel the need to switch to touch typing if the skill you already had was so good?
Half because I got an ortho split keyboard and couldn't use my old technique with it, and half because everyone said touch typing is so much better.
> - Do you regret switching to touch typing? Why?
Yes, my old technique is much more comfortable and faster. I still type the "old" way on regular keyboards, but it's not such a big deal either way, since I'm usually limited by the speed of my brain rather than my hands, and I don't much mind the reduced accuracy either. I'm touch typing this on the split keyboard right now.
> - How many years did it take you to get to 120 wpm at 98%?
I've been typing that way for 20 years, so I can't really say. I definitely remember being pretty good around 4 years in, possibly long before that.
> - Is there anything you miss from your old technique (beside the higher stats)?
It just feels more comfortable, when I touch-type I feel a bit like I'm fighting the keyboard, or as if I'm wearing shoes half a size too small. With my old technique (e.g. on my laptop) I feel at home.
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 probably also helps avoid carpal tunnel, though I have nothing other than my own suspicions (and the 20+ years I've been typing without issue or concern over posture/wrist rests/etc) to base that on.
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.
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.
> I played MUDs as a kid.
For me it was the chat in StarCraft, had to get messages out fast enough not to interrupt the action.
For me it was the chat in StarCraft, had to get messages out fast enough not to interrupt the action.
Realms of Despair represent!
Thank you for your detailed answers, I appreciate them.
> 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.
I think you have a point here. Touch typing may not be "the" technique. We should always be open to new and better techniques and not embrace touch typing as a dogma, of course. And okay, it's only one way to type, and there are surely other ways to type.
I'm not saying that everybody has to learn touch typing because it was sent by the gods. I'm not even the biggest fan myself. I agree that it has its problems and I know for a fact that there are a lot of people out there with their own techniques who easily outperform touch typists.
So I'm not defending touch typing "at all costs".
I was praising it because I have an educator's perspective here and have the general public in mind, especially when I offer general advice in a forum like this. At the start of this thread I was replying to a person who seemingly didn't know much about touch typing.
While there are reports of other techniques that easily outperform touch typing in terms of wpn, accuracy and comfort; there are other properties of a technique that may or may not be important depending on one's perspective.
Let's call them "teachability" and "time of mastery". Touch typing is a very valuable tool not just because it allows one to perform sufficiently in terms of wpm & accuracy, but also because it is very easy to teach it. One doesn't even need a teacher as it's completely public and straightforward knowledge. There are very clear instructions on how to master it, and the mastery happens in 3-6 months. All very predictable and guaranteed. I don't know of any other technique that is comparable in this regard.
And there are so many people out there who don't know about touch typing or realize how much better it can make their lives. Touch typing is their quickest path to better productivity.
I cannot tell those people that: "There is this established typing technique that you can master in 3 months, but maybe don't learn it, because there are reports that there are people who developed their own better techniques in a couple of years, and there is a possibility that you can end up like them".
Obviously, the expert's and the educator's perspectives are different here, so I don't really think we're in a big disagreement.
> 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.
I think you have a point here. Touch typing may not be "the" technique. We should always be open to new and better techniques and not embrace touch typing as a dogma, of course. And okay, it's only one way to type, and there are surely other ways to type.
I'm not saying that everybody has to learn touch typing because it was sent by the gods. I'm not even the biggest fan myself. I agree that it has its problems and I know for a fact that there are a lot of people out there with their own techniques who easily outperform touch typists.
So I'm not defending touch typing "at all costs".
I was praising it because I have an educator's perspective here and have the general public in mind, especially when I offer general advice in a forum like this. At the start of this thread I was replying to a person who seemingly didn't know much about touch typing.
While there are reports of other techniques that easily outperform touch typing in terms of wpn, accuracy and comfort; there are other properties of a technique that may or may not be important depending on one's perspective.
Let's call them "teachability" and "time of mastery". Touch typing is a very valuable tool not just because it allows one to perform sufficiently in terms of wpm & accuracy, but also because it is very easy to teach it. One doesn't even need a teacher as it's completely public and straightforward knowledge. There are very clear instructions on how to master it, and the mastery happens in 3-6 months. All very predictable and guaranteed. I don't know of any other technique that is comparable in this regard.
And there are so many people out there who don't know about touch typing or realize how much better it can make their lives. Touch typing is their quickest path to better productivity.
I cannot tell those people that: "There is this established typing technique that you can master in 3 months, but maybe don't learn it, because there are reports that there are people who developed their own better techniques in a couple of years, and there is a possibility that you can end up like them".
Obviously, the expert's and the educator's perspectives are different here, so I don't really think we're in a big disagreement.
My "disagreement" (I wasn't really disagreeing) is on something you addressed in the original comment: If you're already fast and accurate enough, you don't need to switch to touch typing. I was more offering a counterpoint that some people have independently settled on their own technique that works for them, and that your list of pointers where someone might not need to learn to touch type is indeed correct.
Thank you for the clarification.
> If you're already fast and accurate enough, you don't need to switch to touch typing.
I agree.
> If you're already fast and accurate enough, you don't need to switch to touch typing.
I agree.
This type of obsession with something that completely ignores facts is not healthy. The arc of the universe is long, but it bends towards efficiency.
There’s a reason we’re not all learning touch typing and using Dvorak keyboards.
There’s a reason we’re not all learning touch typing and using Dvorak keyboards.
It's funny. Do you realize that your comment has no content? You speak like a politician. You're just attacking without really saying anything. Maybe answer:
- What makes you call this an "obsession"? There's just a remark and an inquiry. Please point out the obsession part, if you can.
- Ignores which facts? You are responsible with providing at least some of them if you want to be a part of the discussion, do you realize that?
- And what is that reason? The will of the universe?
I certainly wasn't saying everybody should learn touch typing and use Dvorak keyboards. Thank you for the straw man as a bonus.
Read my latest relevant answer that should show that I'm not obsessed with touch typing but have a clear reasoning behind my praisal: https://news.ycombinator.com/item?id=27171906
And if you're going to reply, maybe be a bit more respectful and provide a proper argument instead of empty attacks. I won't engage further otherwise.
- What makes you call this an "obsession"? There's just a remark and an inquiry. Please point out the obsession part, if you can.
- Ignores which facts? You are responsible with providing at least some of them if you want to be a part of the discussion, do you realize that?
- And what is that reason? The will of the universe?
I certainly wasn't saying everybody should learn touch typing and use Dvorak keyboards. Thank you for the straw man as a bonus.
Read my latest relevant answer that should show that I'm not obsessed with touch typing but have a clear reasoning behind my praisal: https://news.ycombinator.com/item?id=27171906
And if you're going to reply, maybe be a bit more respectful and provide a proper argument instead of empty attacks. I won't engage further otherwise.
[deleted]
My comment does have content, but it wasn’t for you.
Yes, your "content" includes an ad hominem and a straw man. And still you are choosing not to answer my questions to clarify your points, but trying to taunt me. Obviously because you don't have an answer. You are not very smart and not worth my time. Bye bye
I'm not sure why one system of typing gets to call itself "the proper technique". Someone made up a system and to promote it called it "the proper technique", I guess.
Also, I don't think that on guitar there is any such thing as "the proper technique". (Musician here.) Different people play the instrument very differently—even within genres, let alone between them. But perhaps guitar was a bad example.
Also, I don't think that on guitar there is any such thing as "the proper technique". (Musician here.) Different people play the instrument very differently—even within genres, let alone between them. But perhaps guitar was a bad example.
Please see my latest relevant comment about this: https://news.ycombinator.com/item?id=27171906
The reason I call touch typing the proper technique is that it does very good in terms of both wpm, accuracy, comfort, teachability and time of mastery. That's why it is more popular than all other nameless techniques. So until there is a technique that does better in all those terms on average, I think it's not the biggest crime to call it "the proper technique". If you don't like it, call it mainstream, popular, whatever.[1] It's the technique every ambitious typist needs to start with at this age (Unless they are already very good). Because as far as I know there is no better technique that is teachable at this time.
As to the guitar comment; there are so many guitar methods. Everybody picks one or another. People who try to learn the thing without help from any techniques / methods won't have high chances of being successful in a reasonable amount of time. (I'm a musician too.) If we agree on the benefit of a technique, when we apply this to typing we naturally come to touch typing. Because as far as I know it is the only documented and teachable typing technique. I'll be happy to be proven wrong. I've been looking for an alternative technique, but couldn't find any until now.
Everybody likes to bash touch typing saying that they have their own special technique they developed over the years that outperform touch typing, but I don't see how this is relevant. We cannot expect everybody to develop their own perfect typing technique over the years when there is already a tried & tested technique available.
In short, what I'm saying is, name a "more proper" technique, and I will shut up. Personal and obscure "techniques" that are not teachable don't count.
[1] And your philosophical argument doesn't really make sense. Yes, touch typing is a human construct. If we can't call it "proper" just because it was invented by humans, then we are in trouble. I didn't call it "proper" because I was implying that it was a gift from the gods. I called it that because there are a lot of indicators that it is the most proper thing that we have available at the moment.
The reason I call touch typing the proper technique is that it does very good in terms of both wpm, accuracy, comfort, teachability and time of mastery. That's why it is more popular than all other nameless techniques. So until there is a technique that does better in all those terms on average, I think it's not the biggest crime to call it "the proper technique". If you don't like it, call it mainstream, popular, whatever.[1] It's the technique every ambitious typist needs to start with at this age (Unless they are already very good). Because as far as I know there is no better technique that is teachable at this time.
As to the guitar comment; there are so many guitar methods. Everybody picks one or another. People who try to learn the thing without help from any techniques / methods won't have high chances of being successful in a reasonable amount of time. (I'm a musician too.) If we agree on the benefit of a technique, when we apply this to typing we naturally come to touch typing. Because as far as I know it is the only documented and teachable typing technique. I'll be happy to be proven wrong. I've been looking for an alternative technique, but couldn't find any until now.
Everybody likes to bash touch typing saying that they have their own special technique they developed over the years that outperform touch typing, but I don't see how this is relevant. We cannot expect everybody to develop their own perfect typing technique over the years when there is already a tried & tested technique available.
In short, what I'm saying is, name a "more proper" technique, and I will shut up. Personal and obscure "techniques" that are not teachable don't count.
[1] And your philosophical argument doesn't really make sense. Yes, touch typing is a human construct. If we can't call it "proper" just because it was invented by humans, then we are in trouble. I didn't call it "proper" because I was implying that it was a gift from the gods. I called it that because there are a lot of indicators that it is the most proper thing that we have available at the moment.
[deleted]
You're referring to things like home-row touch-typing. My experience matches GP, which is touch-typing, but not home-row.
The OP was referring to "home-row touch-typing" as simply "touch typing", as nearly everybody does, so I didn't feel the need to clarify. I don't see how pedanticism helps here.
The first response was not, then your response to that jumped back to home row without distinguishing non-home-row touch-typing from just typing. It's not just being pedantic when the meaning actually changes.
The first response, as well as myself, went from hunt-and-peck typing to non-home-row touch-typing. The first response was confused about why people have to put effort into "touch-typing" when it's something that comes naturally over time, like it did for us.
It's not useful to conflate the two. "Touch-typing" means "not hunt-and-peck", not "home-row touch-typing".
The first response, as well as myself, went from hunt-and-peck typing to non-home-row touch-typing. The first response was confused about why people have to put effort into "touch-typing" when it's something that comes naturally over time, like it did for us.
It's not useful to conflate the two. "Touch-typing" means "not hunt-and-peck", not "home-row touch-typing".
I agree with you, I've always thought of it like learning to ride a bike without training wheels. It's not "riding a bike without training wheels", it's "riding a bike". If you need to look at the keyboard, you aren't good at typing yet.
[deleted]
I'll point out i learned at about 25. im 40 now. at that time i rated myself too.
when my missus goes to bed. i can still game without a backlit keyboard. you can't.
I can. My point is that I can do it without having been explicitly taught touch typing. It's just a skill I developed over time and I thought that it happened for everyone else too.
So you feel for the 'home keys' instincitvely without looking? every time you type? and never had a single lesson?
that was my point. the two little lumps on 'f' and 'j' are so you know where to put your pointer fingers in the dark. touch typers feel for them so they can type without looking. It's cool that you can just do that, without knowing, over time.
To be fair, as someone who is similar in not using touch typing (but hits high wpm), new keyboards do throw me a little bit, and it takes me 10-30 minutes on one to get my error rate back down to negligible. That said, I instinctively know when I have typed an error, even on a new keyboard, and so am already moving to hit backspace before my brain even goes "oops, wait, you made a mistake", so the new keyboard is really just slowing me down rather than leading to bad output.
I've never had lessons, I have no concept of home keys (just had to look up what they are), I type everything without ever looking at my keyboard at a reasonable speed.
Yes.
Isn't this a thing that naturally happens over time? I've never heard of anyone taking typing lessons, even among programmers.
I don't use the home keys, I just know where the keys are. I type with my first three fingers and use the pinky for Shift and Ctrl. I can do 120 wpm and am very accurate at it.
When I don't touch-type. I learned touch-typing years ago and use that too when I'm at my ortho keyboard, but I'm much slower and less accurate than my home brew technique.
When I don't touch-type. I learned touch-typing years ago and use that too when I'm at my ortho keyboard, but I'm much slower and less accurate than my home brew technique.
I don't think this is very unusual for people who spend a lot of time typing.
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.
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!
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!
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."
From the best: "Ambition is the will to try what others won't."
[deleted]
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: all it takes is one team member who is focused on finding problems rather than solutions to basically halt team progress
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.
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.
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.
>we would never schedule for more than 4 hours a day of coding per dev
Exactly right; And that is on a good day!
I like to read about how the "Great Scientists/Engineers/etc." approached their work and have come to the conclusion that they all avoided "busyness" like the plague. Instead they spent a lot of time thinking about What to do and How to do it before embarking on the job itself. Dijkstra famously did everything using Pen and Paper. I am trying to cultivate similar discipline given that the amount of distractions available on a Computer is orders of magnitude more now.
Exactly right; And that is on a good day!
I like to read about how the "Great Scientists/Engineers/etc." approached their work and have come to the conclusion that they all avoided "busyness" like the plague. Instead they spent a lot of time thinking about What to do and How to do it before embarking on the job itself. Dijkstra famously did everything using Pen and Paper. I am trying to cultivate similar discipline given that the amount of distractions available on a Computer is orders of magnitude more now.
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.
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).
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).
Could you teach us some of his best lessons please?
There are so many. Sometimes they're big picture stuff, sometimes they're more detailed.
One of the lessons I learned in my junior years is that I used to write CSS with a lot of nesting and relatively short class names (I used SCSS which made nesting easier) - The CTO kept telling me that I should avoid using more than 2 levels of nesting and to use long descriptive class names. I felt that was against the whole point of "cascading" in CSS. I soon discovered (during the first redesign) that when you have a lot of nesting in the CSS, it becomes extremely difficult to refactor the layout of the application; moving containers around breaks the layout every time. Whereas if you have a relatively flat CSS, you can move around components easily without breaking anything. It seems so obvious in retrospect.
I also learned the importance of having one source of truth and the importance of making sure that each kind of data flows through the system in a single, clear direction (or else you can get glitchy behaviour with certain kinds of realtime data). A common one is to make sure data flows from the source of truth. For example, when you click a component, it should update the URL hashbang, then other components should react to the change in the URL... Don't make the components react to the click directly and only update the URL hashbang as a side effect (because the click event could conflict with the URL change event in some edge cases; e.g. cause the UI to be rendered twice is a common issue). The URL has to be the source of truth.
Another critical lesson was about separation of concerns and the importance of being able to justify all technical decisions using simple non-technical language.
But there are so many lessons. I was fullstack so I learned a lot of backend tricks as well. A different one seems to come up every day when I work with other developers on a complex project. I try to explain the reason as much as possible because sometimes they sound counterintuitive (or I should say counter-narrative) and they're not usually silver bullets so it's important to convey the nuance as well.
One of the lessons I learned in my junior years is that I used to write CSS with a lot of nesting and relatively short class names (I used SCSS which made nesting easier) - The CTO kept telling me that I should avoid using more than 2 levels of nesting and to use long descriptive class names. I felt that was against the whole point of "cascading" in CSS. I soon discovered (during the first redesign) that when you have a lot of nesting in the CSS, it becomes extremely difficult to refactor the layout of the application; moving containers around breaks the layout every time. Whereas if you have a relatively flat CSS, you can move around components easily without breaking anything. It seems so obvious in retrospect.
I also learned the importance of having one source of truth and the importance of making sure that each kind of data flows through the system in a single, clear direction (or else you can get glitchy behaviour with certain kinds of realtime data). A common one is to make sure data flows from the source of truth. For example, when you click a component, it should update the URL hashbang, then other components should react to the change in the URL... Don't make the components react to the click directly and only update the URL hashbang as a side effect (because the click event could conflict with the URL change event in some edge cases; e.g. cause the UI to be rendered twice is a common issue). The URL has to be the source of truth.
Another critical lesson was about separation of concerns and the importance of being able to justify all technical decisions using simple non-technical language.
But there are so many lessons. I was fullstack so I learned a lot of backend tricks as well. A different one seems to come up every day when I work with other developers on a complex project. I try to explain the reason as much as possible because sometimes they sound counterintuitive (or I should say counter-narrative) and they're not usually silver bullets so it's important to convey the nuance as well.
Sounds similar to Ousterhout's Philosophy of Software Design!
https://www.amazon.com.au/Philosophy-Software-Design-John-Ou...
The main point is that a software developer's job is to fix stuff so you end up introducing complexity, but you will have a much easier life if you realise when you're about to introduce more complexity, and try to minimise it by thinking about your implementation choices. KISS, I guess.
https://www.amazon.com.au/Philosophy-Software-Design-John-Ou...
The main point is that a software developer's job is to fix stuff so you end up introducing complexity, but you will have a much easier life if you realise when you're about to introduce more complexity, and try to minimise it by thinking about your implementation choices. KISS, I guess.
Nice, this is a broader way to explain the effectiveness of my CSS approach and many other approaches. IMO, Modern developers should read fewer books about tools and more books about software philosophy. It's far more important.
It's weird to think that philosophy can actually yield productivity gains... Many people think of philosophy as being the anti-thesis of productivity.
It's weird to think that philosophy can actually yield productivity gains... Many people think of philosophy as being the anti-thesis of productivity.
What do you mean by 10x, 100x, 1000x?
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 regular developers. For example, a highly complex project which regular developers do not have the capacity/talent to complete, ever... Just imagine some very complex project programming a quantum computer or certain kinds of blockchain or distributed systems projects; some developers will never be capable of delivering such projects. It's beyond their innate ability and capacity for learning.
Project complexity maximizes the utility value of highly productive developers. It would be difficult to identify a 100x developer on a simple project (they might only appear as 2x) but they would stand out as a definite 100x on a complex project.
That said there are projects for which a developer could be infinity-x compared to other regular developers. For example, a highly complex project which regular developers do not have the capacity/talent to complete, ever... Just imagine some very complex project programming a quantum computer or certain kinds of blockchain or distributed systems projects; some developers will never be capable of delivering such projects. It's beyond their innate ability and capacity for learning.
Project complexity maximizes the utility value of highly productive developers. It would be difficult to identify a 100x developer on a simple project (they might only appear as 2x) but they would stand out as a definite 100x on a complex project.
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.
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.
I regret looking back at my worst moments.
At least you have recognizing and regret for these moments. Truly the worst never do so.
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 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.
And it was solved in one go.
I had a piece of self-talk during outages: "don't worry, type" The more energy spent worrying, or in your story panicking, the less energy and focus available for taking action and taking action is [usually] the only way out of a mess
However, that might also go hand in hand with an "blameless post mortem" culture, because if one is trying to solve a problem and cover one's ass, now there are two problems
However, that might also go hand in hand with an "blameless post mortem" culture, because if one is trying to solve a problem and cover one's ass, now there are two problems
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.
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.
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".
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".
Yeah, overusing this is awkward. The main point is not to assign blame, agreed.
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".
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.
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.
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.
Lot of immaturity out there in that case.
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.
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.
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.
You drink 5L of water a day? (assuming 180lbs, 28ml Oz that's 5.04L)
No no, so it's half your weight in lbs, in oz.
So for a 200lb man, it'd be 100oz. Just under a gallon.
It seems like a lot at first, and for the first few days I peed a lot, but now it seems normal.
Granted, I'm doing myself a small service by saying 200, but that's just a few covid pounds.
So for a 200lb man, it'd be 100oz. Just under a gallon.
It seems like a lot at first, and for the first few days I peed a lot, but now it seems normal.
Granted, I'm doing myself a small service by saying 200, but that's just a few covid pounds.
Ahh.
That makes more sense, I drink about that just for water excluding over drinks.
Pint of water soon as I wake up, Pint before bed and the rest through the day.
That makes more sense, I drink about that just for water excluding over drinks.
Pint of water soon as I wake up, Pint before bed and the rest through the day.
Nice! Good work.
I was terrible about it before. Coffee, energy drinks, sugary crap. I drink almost exclusively water and herbal teas, and I've been staying under 20g of sugar most days for the past few months.
I don't know if you're American or not, but I have struggled with just being surrounded with terrible snack choices and meal choices. It's been nice focusing on changing these behaviors.
I was terrible about it before. Coffee, energy drinks, sugary crap. I drink almost exclusively water and herbal teas, and I've been staying under 20g of sugar most days for the past few months.
I don't know if you're American or not, but I have struggled with just being surrounded with terrible snack choices and meal choices. It's been nice focusing on changing these behaviors.
UK but we are heading the same way in regards to it been easy to make terrible choices.
For me switching to sugar free energy drinks and fewer of them was a big change.
For me switching to sugar free energy drinks and fewer of them was a big change.
Which is not that far off from 5L. (1L ~ 1 quart)
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.
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.
+1 for ‘reputation inflation’! That explains some perplexing behavior/ decisions I’ve seen (mostly from ‘leadership’ folks)
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.
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.
If you were CEO once good luck finding job as non CEO :)
No luck required. I didn’t have a problem finding a job after deciding not to be a CEO anymore (I was a CEO for 5+ years).
I know a bunch of people who founded their own companies and started a regular engineering employment after that.
I don't know anyone who founded their own companies and moved back to being an employee.
Well my current boss or current customer, as I have my single person company and doing contract (well I am a CEO :D), is still in the business so I don't have much to argue.
I also was not looking for a job as a former CEO or for CEO job openings.
I just know bunch of people who had masters degree and were looking for ANY type of job. If they wanted to just earn anything having masters degree and sending CV for a cashier position was mostly useless. I expect there is the same effect in play that someone with CEO experience will be "overqualified" for the job, meaning no one will hire them because:
a) in case they find anything better they will jump the ship
b) if it turns out they are better than person hiring them, well you people mostly don't want to hire someone who can replace them.
Well my current boss or current customer, as I have my single person company and doing contract (well I am a CEO :D), is still in the business so I don't have much to argue.
I also was not looking for a job as a former CEO or for CEO job openings.
I just know bunch of people who had masters degree and were looking for ANY type of job. If they wanted to just earn anything having masters degree and sending CV for a cashier position was mostly useless. I expect there is the same effect in play that someone with CEO experience will be "overqualified" for the job, meaning no one will hire them because:
a) in case they find anything better they will jump the ship
b) if it turns out they are better than person hiring them, well you people mostly don't want to hire someone who can replace them.
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.
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.
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.
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.
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 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.
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.
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.
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.
I also prefer 20 lines of simple pedestrian code to 2 lines of clever code. I remind myself that I write for the maintainers, who do not have the benefit of my resident knowledge when they encounter the code.
if ( unexpected = true )
branch;
do_expected_stuff
I also prefer 20 lines of simple pedestrian code to 2 lines of clever code. I remind myself that I write for the maintainers, who do not have the benefit of my resident knowledge when they encounter the code.
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?
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?
This particular use of an if statement is subset of what's called a "guard clause", and I'm also a major fan of them. Other guards include an early return for edge cases or that would make the more general path more complicated, rather than just exceptions.
https://wiki.c2.com/?GuardClause/
https://wiki.c2.com/?GuardClause/
aren't these ill defined guards?
Favor immutability. Be intentional about where state lives. Ask what happens when you leave the happy path.
Prioritize your backlog to reduce/eliminate 2 AM pages. That's the metric you care about; not tickets, not test coverage, not logging/metrics. All those others are gameable metrics. The only thing that matters other than reducing pages are features, and you'll find that by prioritizing the former, you end up delivering faster on the latter over the long haul.
Prioritize your backlog to reduce/eliminate 2 AM pages. That's the metric you care about; not tickets, not test coverage, not logging/metrics. All those others are gameable metrics. The only thing that matters other than reducing pages are features, and you'll find that by prioritizing the former, you end up delivering faster on the latter over the long haul.
> Every if statement
... has an "else" whether it's written or not. Choose carefully whether to skip writing it, but always know it's there
I try to impress that not as much upon developers, but religiously upon folks writing requirements. Many pieces of code work just fine without the else, but the amount of bugs and rewrites due to someone either not considering "but of course it always succeeds!" or because there was an implied else scenario in their head that they just didn't bother to write down are almost innumerable.
... has an "else" whether it's written or not. Choose carefully whether to skip writing it, but always know it's there
I try to impress that not as much upon developers, but religiously upon folks writing requirements. Many pieces of code work just fine without the else, but the amount of bugs and rewrites due to someone either not considering "but of course it always succeeds!" or because there was an implied else scenario in their head that they just didn't bother to write down are almost innumerable.
This, so much. Every branch or decision point in either the domain model/flowchart/spec/etc or implementation should be carefully considered. This applies doubly so to error handling. Also, try to make the code paths look like or at least be recognisable by the spec. Try to keep one mental model of what happens that the team all share.
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.
Code like Hemingway.
From the worst: always shower and stay up-to-date.
From the best: abstract only when needed.
From the best: abstract only when needed.
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 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 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.
Worst: a programmer with a huge ego. He was extraordinarily defensive about his work and this made the whole team unproductive.
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.
The TL;DR I got from https://news.ycombinator.com/item?id=26722655 was "team secretary".
(That's a subthread off of a _rather_ interesting Ask HN)
(That's a subthread off of a _rather_ interesting Ask HN)
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 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.
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.
> I learned from this that some people are always going to see you like they first saw you.
Yup.
> Your mother is going to always see you as the adolescent with the messy bedroom, even when you're 40.
Nope. She's going to keep seeing you just the same way she saw you when you were the adolescent with the messy bedroom, namely as her little baby.
Even when you're 60.
Yup.
> Your mother is going to always see you as the adolescent with the messy bedroom, even when you're 40.
Nope. She's going to keep seeing you just the same way she saw you when you were the adolescent with the messy bedroom, namely as her little baby.
Even when you're 60.
This is why a lot of businesses (retail especially) don't like to promote from within the same location.
>I learned from this that some people are always going to see you like they first saw you.
First impressions matter most !
First impressions matter most !
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.
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.
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 )
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 )
Avoid projects where someone who conspicuously and officially failed still has influence over, for only your failure will validate his failure.
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...
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...
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.
Life is too short. Or, to put it another way, life is too long.
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.
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.
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.
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: 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.
I've actually collected a list of those bad ones over the years on my blog: http://nywkap.com/other/miserable-teams.html
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.
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.
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.
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.
This is the key to being a "Good Manager"; it is the correct way to show respect i.e. that you matter.
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.
* 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.
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.
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: 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.
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.