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.
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
Best: Talking to people and discussing ideas will get you further than an email. Email should almost be a tool to summarise your discussion, spread to a wider audience and make sure everyone is on the same page.
Worst: That pretending you know what you are doing, never asking questions if you don't know what you are doing and having no sense of humility will lead to your demise.
Best: 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
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.
> 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 ?
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.
> 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.
> 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 ?
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).
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 your manager has objections that's evidence it was a bad idea
You're just pushing responsibility for saying "no" onto someone else. I would look at the concept of "ruinous empathy" - sometimes being too facilitative and not giving feedback isn't good for anyone.
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.
>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.
> 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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
This is exactly why we don't put @author comments in our code. Once the code is in the main line it's owned by the team.
It also helps to promote quality within the team because if you see something unreasonable you are empowered to take action (that may not be possible immediately because we all have our day jobs but at least adding a TODO for it)
The standard you scroll past is the standard you accept.
This only works if the team has a very high standard and some self restraint.
Otherwise notorious code churners who are addicted to a high commit count plow through the code base, regardless of whether they are area experts or not.
If you contradict them, they cite the common ownership rule and paint you as a non-team-player.
If they introduce bugs into the release and you point it out, you are the villain again.
All in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.
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.
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.
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.
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 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.
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.
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.
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.
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...
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.
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.
Classic corporate psychopath. Doesn't do the work, gets you to do his work, attacks you for doing it, and probably took credit for the fix behind your back. Once we can screen these people out of positions of power through MRIs or whatever, the world will improve in a big way.
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.
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.
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 &qu...
269 comments
[ 2.1 ms ] story [ 286 ms ] threadWorst: but it's amazing how long a person can last without doing much at all!
Worst: Apparently knowing how to use excel efficiently isn't better because manual calculations prevent errors.
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: Stay in your lane.
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.
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: be competent, be rude, don't collaborate
Worst: Don't tell employees you pay them so they shouldn't have to use Google.
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.
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.
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.
Worst: Good people can sometimes land in the wrong role. Change conditions before passing judgement.
Worst: some workplaces allow the negative workers on the team to get away with anything.
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 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.
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!
Compliment people behind their back relentlessly.
Worst: The people who talk about others will talk about you
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: Fire them all really really quickly. People that are bad after week 2-4 will never not be bad afterwards.
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.
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.
Heaven is other people.
Worst: Code should be designed for users, not any individual engineer's philosophical preference.
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.
> [ . . . ]
> Quotations mean beliefs of person having such of a approach.
You can learn how not to do something from observing someone doing things wrong.
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.
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 ?
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.
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.
That’s called “The Abilene Paradox.”[0]
[0] https://en.m.wikipedia.org/wiki/Abilene_paradox
Good way of putting it. Too often code reviews devolve into nit-picking and bickering.
"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).
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"
If said boss gets it immediately, I would like to know if he's hiring. ;P
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?
You're just pushing responsibility for saying "no" onto someone else. I would look at the concept of "ruinous empathy" - sometimes being too facilitative and not giving feedback isn't good for anyone.
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.
You can learn how to recognize them faster, or how to work with them despite their behavior, or practice standing up for yourself, etc.
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.
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?
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: 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.
I disagree that going above your boss first would lead to getting fired though (again with the exception of at will employment).
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.
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.
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.
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.
Because I wanted to ask why he would be so mean to you. That insecurity part answers that.
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 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.
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.
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.
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.
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.
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.
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.
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.
If someone else just fixes stuff for you all the time that just might not be good in the long run.
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.
What are some ways to do this effectively?
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.
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.
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.
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...
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.
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.
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.
What do you mean by those that?
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 &qu...