Did you make the mistake of thinking just writing good code is what management really wants? How are you building confidence in you at work? ►► Know your options! Visit my wiki about the top 25 job roles in tech, TechRolepedia → healthysoftwaredeveloper.com/techroles/
There is one flaw with this video though: Everything is presented as if this was always the case, but it's been escalating as computers took over the world. Every industry has some disconnect between management and workers - the question is, can you step over the pothole or is it ravine?
HOW CAN YOU JUSTIFY TELLING A DEV THAT JUST WANTS TO WORK MORE TO GET INTO FUCKING MANAGMENT. How can you sit there and describe the state of development like that without busting out laughing. Our main job is to anonymize accountability and play best buddies? Youre describing a DEI nepo shit hole idiot fest dude. Why would I even want to be born on a planet next to this stuff let alone commit and work on it as if this was value. This is value to a ceo looking to score on indan dev work. Jesus FUCK.
Just remember that most adults are not really adults. They are young children in larger bodies. When you are lucky enough to work with a true adult, treasure it.
I don’t think there is any true adult, only children wise enough to step back and listen before acting. Nobody knows what they doing, not all the time, some just learned to fumble more gracefully, some learn to learn quicker, needing one or two instead of 5 or 8 attempts. Others simply failed so much they can smell signs of failure a mile away. Uneventuslly the world simply makes them fear the unknown
That only applies to Americans. Already in the 80s we used to say: "Americans mature until they are 14, after that they just grow taller". The rest of the world is much more reasonable.
Everything described in this video is more commonly referred to as “Playing the game”. I have often been told “If you want to last at this company, you gotta play the game.”
If you haven't already, check out the episode I did on the first software project in my career. I got screwed over by politics so bad it was incredible. Nobody tells you how the game is played until it's too late. I'm trying to change that, but man people don't want to stare the harsh truth in the face. ruclips.net/video/d4hFQyuKVhs/видео.html
@@HealthyDev The most important advice imho is the one about leaving the paper trail. This will not only save you politically but also legally in the long run, because any verbal agreement in court is only worth the paper it is written on. I do a similar thing, but in the form of a Jira comment on the ticket, "how we decided in the standup to handle it". Make it a habit.
@@markusjohansson4949that’s the definition of politics. As Patrick Lencioni says in his incredible book “The 5 Dysfunctions of a Team”. It’s when everyone tells each other what they want to hear - and not the truth. That’s definitely dysfunctional on a systemic level and different than what I’m advocating here - measured communication of problems. If anyone asks me point blank whether there’s a problem with something I always tell them the truth.
Warning management about problems is always a mistake, they will think you are causing it when you end up being right. Rather than preventing it, you are better off preparing a solution and letting the problem happen then fixing it.
@@beowulf_of_wall_stThis is dumb because there are some problems you clearly cannot fix. They just don't care about reality and are bad managers. They need to fix themselves instead of me fixing them.
@@beowulf_of_wall_st This is totally counter-culture for me, I'm caring about the customer too much. But on the other hand I totally see no other way as long as it's not my own company...
I hate all the points raised in this video, but most of all I hate the fact that he's completely correct. Its a sad world we live in where productivity and efficiency are held back by mismanagement.
Thank you. I don’t enjoy having to share this stuff. I do this because I genuinely care for developers. Coaching them is my job. If you heard the stories I do of what people are going through, you’d do the same.
6 месяцев назад
Blaming management without taking your own responsibilities toward it is creating more problems than solving it. As IC, we have way more power in changing things around us than we care to admit, and when we do, we often expect our managers to do it for us. Why do we need a scrum master to change a status update into an effective meeting? Why do we need the PO to wait for the PO to clarify a story? Why waiting for the team manager to write down an onboarding manual for review guidelines? If you think that the improvement is worth it, then there shouldn't be a problem doing it as part of your role, as long as you don't neglect your priorities.
When dealing with idiots, you have to be diplomatic, especially if the idiots wield a lot of power over you and pretend you're bending into their dogma. Of course, this can backfire and when the shit hits the fan YOU will be the one getting fired, because they will never take the blame, but that's another story :)
The "don't highlight problems" is so true and only becomes more true as you move up the management chain. In most businesses, it's better to let a dumpster fire continue to burn rather than be the one that points out the fire. It's not healthy or good for the business but in terms of career advancement, you'll never be rewarded for pointing out problems unless you've already solved them. If you need help or it requires cross-team effort to fix...just don't say anything. The safer path is to let things fail and have enough documentation to prove it wasn't your fault.
Jesus this is why I’m so burned out in IT. What you are saying is true, but for someone that can’t ignore issues, it’s constant stress. It’s also the reason IT systems keep getting less secure and less reliable over time.
You're absolutely correct. I wish it weren't the case, but it's reality. Unless your job is to be actually responsible for the cross-team efforts, trying to take responsibility for them is just setting yourself up for being blamed for things outside your area of control.
@@HealthyDev I learned this lesson the hard way. Dev team ends up being Tier 3 support for everything but nearly 100% of our outages were infra or DB related. I tried to fix them and while those teams were easy to work with and willing to engage, they had skill issues that negatively impacted the business's perception of me when they couldn't execute. Lesson learned the hard way but better to learn it now.
I may be a rookie about this but to me it's just sounds like bad ego of the management/those that are responsible so why should I respect that? If you buy hardware from an external supplier and they don't deliver on time or in the quality they promised, you expect damages, discounts or cancellation too.
I have made this mistake. I predicted a 18 month overrun on the project. I was given a warning letter for "negativity." I told them they were punishing good engineering knowledge. BTW the project overrun 2 years so I was overly optimistic in fact
At my former corporation, a Fortune 100 food delivery company, several people who pointed out based on math that the sap conversion would not work. They were all fired. We were explicitly told that we had to run at the problem fast enough to overcome the hurdles instead of identifying risks and eliminating them. And that we needed to maintain a positive attitude that the conversion would be successful. After the 10th conversion, they laid off most of the existing IT staff and replace them with infosys. 6 months later the entire conversion failed and they changed to another Consulting Group and rolled back the entire sap conversion and sued sap. (and they rehired about 20% of those let go at premium rates).
@HealthyDev I retired at 51 in 2012. I was extremely lucky. They laid everyone off one day before I was going to give notice. So I got 12 weeks severance instead of the 5 weeks vacation time I was waiting to vest. But it was pretty bad. My blood pressure was 166 and we had several heart attacks plus one Deloitte consultant in his thirties was taken out unconscious by paramedics and we never saw him again. In the end, they realize that they really did need big iron and the cloud computing wasn't going to have the processing power they needed. The whole project was supposed to save 100 million dollars per year in salary costs but the cloud computing estimate for a complete conversion was a billion dollars per year. And the HR department became extremely leaky about facts after the layoffs were announced.
@@HealthyDev the longer version is at 30 I had testicular cancer and had 5 months off work with pay. I realize I didn't get anything out of working at all and I just wanted the money so I started Living on half of what I made and after 21 years, I made my numbers. But the last two years were brutal. I literally slept in my car in the parking lot more than once and we had to work over 80 hours a week several times per month for the last 12 months.
This can be subtitled, "How to survive in a dysfunctional organization." I also see a lot of overlap here with Robert Greene's book "the 50 laws of power." Finding that book opened my eyes to why I was being constantly passed over in promotions at work despite getting positive reviews and completing a reasonable workload.
48 laws of power is a great book for understanding the Machiavellian tendencies in people. And some of my advice does pertain to dealing with it. I hope it's clear I'm trying to advise people to deal with it by using strategies that still help us to be ethical in the face of it though. I don't think we should be employing many of those laws directly as a way to manipulate people. That's just my position of course.
@@HealthyDev A lot of your advice is directly in alignment with many of the laws. Minimize imperfections, praise others, don't outshine the masters, vye for visibility (court attention), etc.
I can't stress enough how accurate and valuable some of these advices are! As a software developer, I often voiced concerns only to be dismissed as negative or naggy. Over time, I learned to play along and celebrate our disastrous projects as if they were brilliant. Ironically, this facade earned me promotions and respect. It's a sad and ridiculous truth.
"Elevate Your Coworkers", number one best piece of advice. This is the best "long term gain" technique in my experience, in the short term, it may or may not pay off, but in the long term it always pays off.
As a consultant I started to coach the customer's technical team to present my findings at the end of my gig. This was after one of my earliest gig where the CIO asked me "Why did my people not know this?". This had an effect that I didn't anticipate. From here onward, teams wanted to work with me more because they were learning so much more. A lot of consultants think they walk on water and keeping the information is the secret to the next gig. It's actually the opposite that works best.
"Reduce throughput". That's a tough one to hear but it is very true. I use to "over-produce" and it just bites you in the arse. Management begins to believe every code-change, feature, bug-fix, should be completed in a few days. When I recognized this, management was asking me to complete mid-size projects in one - two weeks - managers who have ZERO s/w development experience. This is where I began to negotiate lengthier commits to "train management" that writing quality code takes time.
@@doughboy_6439 you mean like match their story points per sprint or something? That's a really bad metric. No two story points are the same (you probably know this). On top of that it encourages people to release low quality code to game the numbers.
@@HealthyDev I can be worse than story points. I've worked at places where there was immense focus on what the business can see / feel and no time spent on invisible elements. Sometimes an individual runs around building new features and piling up the tech debt while another team of underappreciated people pay it back down. I do think most points you make are correct but the extent matters a lot. Many places can handle tech debt in a more mature way. It's like saying there's always bacteria on your food. True but some meals are tasty and others will kill you.
typical sprint cycle at my old job: > get assigned task for an idea that clearly won't work > tell boss your boss that an idea won't work > write an essay why it won't work > still get assigned the task It took just 5 years of this for the hair loss to set in
Also: very typical for organizations to have "sprints" that are nothing like actual name-brand Scrum. Like, fundamentally a) your boss isn't part of the Scrum and b) you don't get "assigned" things in the sprint. I think these things go together a lot. Shops that have "sprints" that are _exactly the same thing_ as two-week deadlines.
@@markw.schumann297that's so true. The point of sprints is to empirically measure the work capacity of a team at a sustainable level, and keep it consistent and predictable. Most managers seem to think that the point of scrum and agile is to increase productivity, while it's actually, and I quote, "maximize the job that is not done".
Story of my life. The time spend on cleaning up the mess afterwards could've been used to implement something that actually works 10 times over... For the love of god, trust your experts and don't overrule them when they raise issues.
@@ElHipokondriako And that's not self-evidently the goal of every project. I have worked on projects where they *want* to maximize the work for various reasons. That's fine, there are all sorts of business reasons for wanting a project to be bigger in some way. But then you should not be trying to use Agile practices!
What he is describing is basically bad management. Sadly there is too much of it in the software industry. The real problem is that there are not enough managers with over a decade of engineering experience under their belt. This is a symptom of a young industry. Imagine an oil and gas firm, say Chevron, where all the people managing engineers and engineering projects have zero engineering experience. The result would be a disaster, from a safety hazard standpoint and commercially. Maybe it was like that back in the "wild cat" early days of oil and gas, but not now. Look what happens when an established engineering company is managed by non-engineers. I give you Boeing. What happened to the share price this year? ... I am sure you get the point.
You're absolutely correct. I'm suggesting solutions given the imperfect system we all work in. I'm an optimist at heart (believe it or not lol). I've just found sometimes it doesn't help people to sell them on how things could be better if they're suffering right now. Hope that makes sense.
Scroll way down to find this. If you coded well and the management promoted the "confidence" guys instead, that's their problem, not yours. If they didn't encourage you to have work life balance instead of burnout on an overscoped project, that's bad motivator and bad planning. Find the good manager instead of "playing the game", or become the manager yourself and change how it works for others.
@@vNCAwizard Long story short. She made a lot of decisions which made AT&T money over the short term by cooking the books but neutered them long term. She gave loans to companies to buy equipment off them but somehow removed the loan from the balance sheet so the only thing that showed up was the income off the sales. Billions in loans. When all the loans came due to be paid off by who she gave the money too she was already out the door and at HP. The only thing that saved them was Lucent had so many patents under Bell Labs that AT&T could sell their entire share of the company to others that just wanted the portfolio. Whole thing got swept under the rug in the fallout, otherwise it'd have probably been another Enron.
I've worked on so many projects where something unexpected comes up for any number of reasons. All too often managers yelled at me, called me incompetent, and much more as a result. This was even showing them what the issue was, potential solutions, and decisions that need to be made. As for "Jamie isn't responsible for Operations" - the lazy manager would typically come back and say "well, that's still your problem and you need to work with them to figure it out!"
Thanks for providing an opportunity for me to offer some clarification, this is great feedback. I consider a dependency someone who has ownership for something you're dependent on. If you have to do part of the work with them, you're a collaborator. And absolutely management will hold you accountable if you don't make sure the collaboration happens.
@@HealthyDev Yes - collaboration is important. I've had a couple of managers who refused to help out or otherwise assist with escalation, so I had to much of the leg work myself. Learned a lot from that process.
I've been a software engineer for 6 years at a Fortune 100 company, a small start up, and then at a FANG company. This video is unreasonably true. The definition of a "good developer" to leadership is one that makes management feel good in that moment. You have to internalize that, you have to go on a journey of discovery to understand what makes the management feel good in this moment, and you to comport yourself to that standard. If you don't you will be punished for it 99% of the time. How much you enjoy working at a company is intrinsically tied up in this. How much your mental health is affected is tied up directly in this. How much your career progresses in the company is directly tied up with this. No amount of personal effort, no amount of beautiful code, knowledge of the best new framework, nor indeed how many LeetCode problems you've solved will ever change this fact.
@@MartinoNotts Yeah, the one thing I'll add to this comment is the following: You also have to accept that there are scenarios where management simply cannot get what it wants (often because what it wants is impossible, either due to time constraints or simply reality forbids square circles), and you're the one who will take that beating. And sometimes, it can be a bad, bad beating. These are the moments where you're going to get fucked, management will lose trust in you, and there's often very little that can be done to mitigate the situation, especially once trust is lost. And the sadder reality is that you just have to accept this and move on. It's better to switch companies and start at 0, rather than try to go from -100 to 100 once management has asked you to do the impossible and you've failed to do the impossible as expected. Sad fact of reality, but it's also why 2 year stints at companies is so common. When I was at the FANG company, I was in an unwinnable situation. There was no way management could be happy because their management didn't know what it wanted, leadership at the highest levels was absent, and most importantly what they wanted simply could not be done (and it certainly couldn't be done by hot dropping a bunch of newbies into a politically precarious situation with no 0% support, 100% blame, and 5% credit for any accomplishments). We couldn't move like a start up and wave our magic wands on red-tape and mountains of tech debt, and deal with changing our minds about what we wanted every 6 months. I wish I had advice or something pithy to say to myself 2.5 years ago when I joined that FANG company, but in all honesty, I've been unemployed for 6 months and am still reeling from burnout.
I've been out of the industry for close to a decade, but I've been thinking about returning. Hearing this video triggered a lot of memories in me that frankly... "make my blood boil". It helps me to realize why bums would rather eat cold expired soup out of a can than go to work. I love coding, but I hate everything to do with business politics and kissing ass. I refuse to do it. I guess might just have to stand on the side of a freeway off-ramp with a cardboard sign that says, "will code for food".
For me, I have done a lot of this partly due to my autism. I communicate directly. I don't naturally see hierarchy. I point out issues and problems in the code, standards, processes, etc. I don't know how many times I'm told "Well, no one else is bringing this up." I even try to relate my behavior back to company standards (which as one might guess, doesn't go over well). It's really hard for me to see value in doing anything but direct communication and it's exhausting to "mask" all day at work. I am thankfully working now for a company that encourages neurodivergent people and I've had managers take a different look at how I present myself when it comes to these things. There's still some on the business side that aren't always ok with it, but when they see the results I deliver they usually accept it since the results I deliver for them make them look good. There is always room for improvement for sure, but I'm glad companies are becoming more aware that for people on the spectrum, this is who we are and we don't do these things to be abrasive or confrontational.
Appreciate your perspective here. You may consider letting folks know upfront your intentions. Also, keep in mind that your PRIMARY job is not to point out problems. Every business on the planet has problems. Lots and lots of problems. That’s why engineers and managers are hired: to SOLVE the problems. Focus on prioritizing and solving problems. Pick your battles.
These are good tips but always apply them In balance. I've seen people super successful at playing this game for a year or so until they got let go with adjacent reasons: "Not delivering enough", "Not highlighting problems early enough", "Not ambitious enough - cause they are not committing to enough things" and even: "Lack of leadership material" because of the fact that they were not specifying which dependencies were acting as blockers.
Those are all real problems. I said not to state the person specifically responsible for a blocker, not to avoid raising it at all. Unscrupulous people can use any excuse in the book to justify letting someone go, so at the end of the day there are no guarantees. I'm just trying to offer some practical tips that will increase the likelihood that you don't do something that gets you looked at negatively that could be avoided. Hope that makes sense.
@@HealthyDev Yeah, reasons are sometimes made up. I've once heard "acting weird" but there was no answer for "Could you please provide me some examples, so that I could work on that?". And the question was not in the context of negotiating to stay, I just genuinly wanted to know what was that "weird" behaviour. I believe it was getting sick for a month though.
Oh man, it's like you have done this video for me. I'm really getting frustrated with my management not seeing value in what I do, the several languages and technologies I have to juggle with, the problems I communicate.
Hang in there. I hope this year you can find some ways to let go a little bit and focus only on what you can actually control. Easier said than done, I know.
Systems engineer here. Yep... it's for us all. We deal with this kind of constant nonsense all day long. all over the industry. It's not just in programming and development.
Actually, I have been warned about a toxic culture in US companies. Allegedly, there is a usual "game" in big tech where the middle management tries to attack the messenger (the one who reports issues in their deliveries) and downplay the issue, while at the same time their engineers are already secretly working on a fix; when the downplaying works then the fix is released secretly, and if not (and the issue is escalated to higher management) then there is a good chance that they can present themselves as those who found a solution "just overnight".
I recently figured out that people don't like being told their ideas are bad. When assessing risk or disagreeing with a topic, I found it better to ask questions addressing your concerns and essentially place confidence in their statement on them. I.e. "you have revealed the risks and are willing to pay the price of the fallout". I'm still trying to practice this in my day to day job, but it essentially is a game changer when dealing with leadership, especially upper management such as directors.
I had to do something similar at my last job, where I'd worked for 14 years, and I despised it. Having to ask genuinely stupid questions in order to gradually lead my boss by the hand like a baby to what the problem with his plan was, all because if I just said what the problem was and what the solution was he'd always take it as an attack on his person and would respond with a counter-attack. He couldn't stand anyone ever saying that his plans weren't perfect. This was for even the smallest detail, like an issue in scheduling, work flow, or a mistake in a set of instructions for the workplace, and it only got worse when he got closer to and eventually passed retirement age.
@@HealthyDev Was it effective? Sure. Did it, along with a multitude of other issues with my boss, lead to me having four mental breakdowns in a year, wanting to self-delete, quitting my job, and currently being unemployed and on antidepressants? Yup.
@@DefaultFlame oh man. I'm sorry that sounds horrendous. I had some personal issues going on that contributed to my mental problems and depression. But yes work was a huge part of it.
Yes, the advice is healthy for a career, but some of it is toxic for delivering value. At the end of the day, my job is to deliver value to a customer: that the customer hands over money and doesn't sue us is the only thing.
I hear you. Unfortunately you can’t deliver value if you’re not trusted because you’re unaware of the optics of how your work impacts other people. That’s my intention here. Delivering value is the goal. Often it’s being done in an imperfect system.
@@HealthyDev this is true. As a minority developer, you find this out alot sooner which enabled me to see this and adjust for it. Gaining trust is absolutely essential and it's easier to understand human nature than to be a purist, you may never find a "perfect" place for that.
'Document verbal decisions' was one of those I had to learn the hard way - how many of us have spent hours grinding, grinding, grinding, only to be told later "that's not what I said" - AWFUL! 'Elevate your coworkers' is something I've been doing more of, and it has definitely shown results. It's hard because our industry tends to be sort of individualistic and competitive, so it feels like you are going against the grain, but I think teams thrive when they can know 'when to compete' vs 'when to compliment'
I actually got fired over one of those verbal decisions that didn't get documented. The guy actually using the feature said they wanted this automated email feature to work one way, so I did it that way, and then months later I got a performance review that said I screwed up that feature. What was actually wanted was never documented anywhere either, but I got all the blame for it.
Also try to do prototyping and let the Product Owners see how it's going to work early. Then they can say that's not what was meant and have them rewrite the ACs. Also change ACs with the permission of the PO and suggest ACs in a text.
Documenting is still not a bulletproof solution. A manager can still claim that the conclusion you wrote in the email was overruled in a later meeting or that he said otherwise once at your desk. In the end, it's you against the person who pays you, and it's a matter of how hard you're willing to oppose this person to prove your claim.
It's a bad saying because not all known problems have a known solution. If they would have, they would have been solved, making them a problem no more.
@@ForgottenKnight1 It goes back to the "The customer is always right[.]" quote. Everyone seems to forget the engineering process and skips from [issue] to [done] rather than brainstorm to discuss ideas before coming to any possible solution.
Man ... 2.1 spoke really hard to me. I was fired from a company with the largest database in the US (probationary period) because I was raising a whole bunch of security issues to management about vulnerabilities in their software and their processes. I was asked to leave at the end of my first week. Their incompetence will come to bite them in the ass one day.
Man! I’m so sorry. Security is one of the only aspects of software development I would think that point does NOT apply to. Fear can make people do crazy things…
And unfortunately this attitude is very common at companies. If you let them know about potential problems they call you negative, a troublemaker, bringing down morale and various other sorts of nonsense.
- have a solution before you present the problem - record all verbal decisions Great advice, especially the second one. I have inadvertently been saved by doing the second one, just by coincidence of me preferring to communicate in written/typed form, from some scary situations that I had been directly involved in.
A good developer tries to understand a problem well before trying to find a solution. But this is not how managers are usually thinking. They don't want to hear much about problems, they want solutions.
All true, but then they could attack us about our time, when did we have time to think about the problem and the solution? We should have been doing something else.
@@andrejszasz2816 If the problem was something about the product or the company, they are dumb. Just. Dumb. And the shouldn't be managing anything anymore.
I 100% use some of these tips quite a bit. Especially when communicating to management about a question, or concern you have. Always, EVERY TIME reiterate your concerns by email after your talk with management. This is incredibly helpful when you have a manager who is either incapable of accepting responsibility for a mistake, or the type to always deny everything. In my line of work its called "Cover your ass." I could not tell you how many times a written account of a meeting has saved my skin over the years. I think the biggest problem that we have with management and bosses in general is that they do not have the time, or energy to fully understand the work of the people they supervise. They only see a small section of it and forget about the iceberg effect. 10% of your work is highly visible to your supervisors, while they in general have little to no idea about the other 90%.
This was a super useful video. I definitely often struggle with status updates because the problems I'm working on can be so specific that I'd have to provide a huge amount of context. I really like the point about highlighting other people's achievements. I do that with my friends all the time and it does absolute wonders, I should do it more in work. It sounds absolutely worth it to use the time gained from reducing your throughput to do things like writing status updates, crediting people and building team morale. Spending time building morale is the sort of thing that is very easy to sacrifice when in a rush, but you're right that it pays huge dividends in the long term for both you and the team / company.
Absolutely. I'm getting too many comments that people think I'm saying to just do these things I recommend and then not do any work. It's not an either/or thing. It's totally possible to do both as long as we account for it in how we estimate and commit.
Once upon a time, as a newcomer to a project, I wrote a document describing 40+ problems and their proposed solutions. The team acknowledged it and even thanked me for "bringing it to their attention". But nobody did anything. In the end, it was I who fixed all those problems in the course of year and a half.
Understanding the problem is half the battle won. When you have people under you, perhaps you can communicate what you need from them to solve these problems. But most of the time, I think it is healthier for the team to just work on solving problems they find. Difficult to develop this culture but so far my teams that I have managed work this way. We do our best in our roles and we seek to fix the problems we see. Even if the rest of the world doesn't. We complain like it is a sport but we enjoy each other's company.
lucky you, I got fired for describing the 30+ problems.. the head of the branch did not want to change the obvious problems and having someone point out those problems put his competence on the line.. which transformed into a big target on my back! what a terrible company that was
@@o1-preview hmm sounds like you dodged a bullet of a company. But I think you should have just fixed the problems and then if they still did not accept it, then leave. Undermining the trust people have of the people around you will not help the team unfortunately. I'm sure you've had times you went back and realised what you've built was not the most efficient or may have been over engineered. But that was the best decision you could make at that point of time. I'm sure there will be people that appreciate the thought that went to it, but you wouldn't want those decisions to affect the trust that people have in you. Especially if 100s of people need to trust you to make a decision in order for the project to continue smoothly.
This is so heartbreaking to watch, but I can see how it's all true, and why I didn't get the promotion I wanted at my last job. Thank you for spelling it out - the cynical view is that corporations are lying through their teeth about what they want. The compassionate view is that they don't *know* what they want. Thanks for peeling back the curtain and showing us how we can *actually* get ahead when our technical skills aren't what's holding us back. I have a huge problem with overcommitment. Then I get burnt out and quit. I've always been afraid that if I promise less and deliver less, I'll get fired or "be the weakest link" - but working as hard as I can and putting in overtime hasn't been helping me get ahead either.
Overcommitment was my calling card the first 15 years of my career. It's OK, we all learn at different times. I still have to practice setting better and more realistic boundaries.
Thanks for speaking up! This is some awesome actionable advice that I wish I had been given at the start of my career. Also these are unspoken rules that no one ever says out-loud because it would make them look bad, but you NEED to know them if you don't want people to make an enemy out of you in less than 3 months time.
Even if I learned some of those points the hard (and long) way, I still find extremely hard to cope with the fact that most of those problems exist only because in the business world people are way more often concerned by the way they look like than figuring what's best for the project and the company they are working for.
I’m right there with you. This wasn’t a fun video to make, in that I knew it would possibly raise visibility of some negative aspects of work culture. Ultimately I hope it helps people keep their job and the confidence of people that care too much about appearances, which turn out to be many of them.
@@HealthyDev Don't worry, your video is very useful. Knowing the truth is valuable especially when it is ugly. It took me about 20 years to realize some of those painful points. Now I probably need two more decades to accept it.
I’m not an IT-related Engineer, and all the recommendations you provided apply 100% to my role, and completely align with my own personal experience. You probably already know this, but you still chose to direct this to just programmers, because you don’t want to make assumptions, and you are cautious and humble about your own knowledge and wisdom. This actually says a lot about you as a person and the level of consciousness you have developed. I subscribed.
oh boy that's hard advices. it makes the work place a little grim. Like, tech company are not following the scientific code of ethics, management just want to hear good news. thanks for your insigth, i feel less naive. Awesome content ! and nice guitar :
Thanks! Humans in general like to say we're virtuous and ethical, then do whatever is self serving in reality. As soon as you can embrace this, things get a lot easier. I choose not to play dirty like many do (did a video about this a few weeks back). But I also have just accepted you're going to run into bad actors.
Top best video you made. Important to be authentic, but be aware of interactions with people. Sometimes you forgot the rules and this was a good thorough freshup of things you can forget when busy in the project. Thanks!
Dang! Everything you say I can so relate. In the past I took on the role of being an all-in-one IT guy (e.g. IT and network support and Software Developer). I never had to deal with most of the things you talk about until now. Great stuff man, keep up the good work!
Thank you! So if I understand correctly you were a "one man IT guy" and now you're on a team, running into some of these issues? That makes sense. It's a very different experience on a team, for sure. Hopefully you're adapting to it OK.
Speaking about communicating problems and doubt: I had one colleague on my team who was pointing out a ton of problems and pushed them relentlessly through to the end, without mincing his words much. He got on bad terms with the project manager. He eventually quit the team because he saw no end, and management wasn't working with him since they saw him as getting too personal about it (which honestly he did). The second was a 30 year senior dev. He saw the first one and commented that that guy was trying to change too much at once, and that with his own experience, he learnt that you can only push so far. Well... they're not prolonging his contract because he spent the year also getting animated and pissed about all the different issues in the project. Both of these absolutely dominated the refinements with by far the most questions, sensing large problems ahead or demanding a huge amount of answers while complaining that the user stories are half-baked. It does feel like the project lead and management eventually got rid of them and surround themselves with anyone who finds these guys annoying.
Thanks for sharing, that's an excellent real life story to drive home the points I'm making in this episode. I talked about this in another episode since this one, that some people seemed to take this video as an "all or nothing". Meaning you either don't care about how you're perceived at all, or if you do you're just an "ass kisser". The truth (in my experience) lies somewhere between.
My last role was Delivery Manager. Around me, I saw nontechnical sales people making half of the money, nontechnical managers causing the worst problems, and the facade of “confidence” winning over good engineering. I decided to pivot back to engineering roles, seek engineering-driven cultures and managers. Many companies have predatory products and selfish cultures. Don’t drink the cool-aid. Mastery should precede management. I’m focused on data engineering. I’m a data plumber. If that means leading scrum or putting on a product manager hat because folks are looking to me for architecture, prioritization, structure, or mentorship, I’m game. But domain mastery is my focus, and the leaders I respect most are masters of their crafts first and managers maybe fourth. That’s my new paradigm.
So basically we need to do the managers job for them, prioritize problems and solve the critical ones, all while telling management everything is going according to their schedule, then when it all falls over, make sure you can prove it wasn't your fault.
If you go back and listen to point one (which I believe you’re referring to) you do want to make management aware of issues but in a patient, incremental way. Hope that makes sense.
@@HealthyDev I mean I've been blessed with good managers pretty much my whole life, but some of the stories I've heard it sounds like they cause more problems than they solve.
You could definitely package shit nicely and with a ribbon. You are absolutely right about the difference between our perception of ourselves snd company’s perception of what value we bring.
I retrained to became a developer after almost 20 years, of which a decade was as a people manager and stalk holder on projects. Unfortunately this is mostly true, but I can say with confidence this is mostly a symptom of bad management rather than the way it should be. And it is not just an issue in software. It is a frustrating reality that we need to "play the game" until you are promoted to a position where you can actually implement changes, but at that point it no longer benefits them (and may even hinder the own management targets). I would say these issues are more prevalent in US based company cultures in my experience, and some European businesses have been a lot better; however it more usually comes down to the relationships you build with individuals around you. When those good people leave, it is almost always time to start looking too.
Networking consultant for 7 years here, can fully understand and agree. Item i woult add in my profession: You have to determine, if the mangement wants actual security (and/or HA) or only on paper. Makes a huge difference when it comes to ressources needed for system + process integration. (Test environments are basically no topic since the hardware (+suscriptions) are insane expensive.)
I learned real quick early in my career that the work I do doesn’t matter. Relationships with coworkers and upholding an “image” will get you further in your career much faster
I wouldn't personally go so far as to say that the work doesn't matter. But yes, doing good work with zero concern for how your image is conveyed is probably not a smart move.
I agree that a good skill is being diplomatic about how you make criticisms or explain technical complexity to the corporate overlords. But I also think that needs to be STRONGLY counterbalanced with honesty. I see a lot of devs who either avoid saying anything or just outright lie about things to make management and other devs happy. That is shortsighted in my opinion and while it does initially inspire confidence, months later when the problems they concealed come out, it erodes overall trust.
Being diplomatic, getting them in a receptive mode, presenting the findings as being for the collective good (although with a mature management it may also payoff for personal good, but most likely it may cause personal harm) is the way to go. I would not hesitate in presenting critical bugs, even though I have lost one job for the same. And it happens at home too. The spouse/parent saying don’t think negatively.
Thanks for your feedback. My intention with this episode is definitely not to lie or be dishonest. If you watch any of my other episodes I'm constantly calling people to higher ethical standards even if it makes them look bad. When we overcommunicate problems or doubt, I don't think this is being more honest. It's not respecting that people have real thresholds of how much negativity they can handle. When we act like we can just spout endless problems (no matter how valid) and people should just "deal with it", we're not being sensitive to human nature. That's just been my experience.
@HealthyDev I get that too. And I wasn't advocating for the person who is just brutally honest and calls out everyone's mistakes all the time. That is exasperating. The thing is, I think that person, the quiet ones and the yes men all have a common trait, which is an attitude of superiority and a lack of trust and respect for other people. And I agree with your point that we need to show confidence in our work. One of my weak points has been a tendency to overshare about my own struggles which does sometimes lead to a decrease in the confidence other people have in my work (especially from that guy who loves to call out everyone else's mistakes). All I am saying is that it needs a balance. We need to be able to be honest while still building a healthy rapport with our coworkers.
That's inevitably what happens. You can't know how much is too much or when is too soon to raise concerns, so people eventually just keep quiet and make sure nothing can get blamed on them.
I am a manager and have some coders reporting to me. The thing that people have to realize is that there is set budget, priority, deliverables, timelines, and client relationships that all have to be considered in context with these problems that are being brought up. It's a delicate balancing act and there's no such thing as perfection. There is such a thing as an "iron triangle". Let's say I do want to fix some of these issues that are being brought up, I may need to go get funding first to be able to do that. And before that I need to deliver on certain commitments that have been made. Management isn't about having absolute control, It's about achieving balance between multiple competing factors.
Yes, but... If you literally force all coders to shortcut many business rules, so that in fact data becomes randomly inconsistent, in many different ways because each client has other settings... You eventually will burn out those who have to do the support with 200% effort from 6AM to 22PM, each ticket being an emergency
Management is also about transparency, if your team isn't aware of what you have to do to make things happen, you can't expect someone just to assume or realize this out of the blue. Communication is key to get everyone aligned.
Most devs will understand all your dependencies towards other teams, clients, upper-management or budget etc. The usual problem is, that devs are treated in a "need-to-know" fashion about these things. Include them as much as possible in the whole process or at least offer it to them repeatedly. It will decrease friction and increase developer happiness.
Thank you for this wonderful lecture. I am working at my office for 4 years and I did some bad mistakes. But over the time I realize that I need to overcome these situation and move forward with my career. This lecture just clarify what I actually need to do. Lastly THANK YOU so much. Love it.
These ring so true. I’m at that phase in my career as a senior software engineer where I’ve learned that I’m on the autism spectrum (shocker, a software engineer on the autism spectrum). All the weird problems that arise from my communication with most other people are finally making sense (particularly communication with managers). I’d realized a couple of these, but not quite as well fleshed out. Many thanks for the clarity.
Wooow this video was shot at the right time, I am precisely at this moment in my career. We are starting a new project and we failed and lost a client using the methods they are using now. I been voicing a lot lately and. it was all in a bid to get architecture better. Been in a meeting with management and the CEO approved a solution I provided but I think I lost some peers to the solution. Given I am fulltime frontend I think I been telling backend to up their API games a little, I may have got me some less friendly peers based off it yet all I was trying to gun for was a smoother way for the project to actually have life.
So much familiar. Reporting problems itself can be a problem. I hate most of managers in ordinary company, too. Good managers let subordinates feel safe but yours were different I guess. In my case, I went with "fix before reporting and make a mountain of (solved) problem reports" and "produce fuckton more" to annoy with my managers. In every company, executives picked me up then chairman picked me up and tasked me with something very secret to realize their goal. My advice is "be confident. do not hesitate. solve problems as many as possible". Other developers who are slow and quiet won't last long. They are there to drag you down. Ignore them. Under such an environment filled with cowards, you can go as far as you think you can go.
What I have noticed for a long period is that in any gacet of life the one that is hated the most is good people, people that speak the truth and people that actually wants to make things work, they're seen as negative people and they're suffered the most
Really good points. This resonated with me big time. I used to worry about problems that weren't my own all the time. Ultimately gaining the perspective that I can share the burden with others and continue on with my own duties is what led me to salvation. Also a healthy amount of uncertainty in my own worries, that theres a high chance it wont be a problem. Other people aren't in my head. When they evaluate my productivity, they measure it by what I am supposed to be doing and accomplishing, not based on whether or not I'm completely content and at peace with what I'm doing and how I'm doing it. From a burgerking burger flipper perspective, your manager evaluates you by being on time, and being dependable in your burger flipping duties. The manager doesn't care if you found some neat way to make the burgers tastier or theoretically safer. That isn't your job, and you will be evaluated on performing your job.
One big issue with softwares is that its damn difficult to quantify almost any aspect of it. Be it security, maintainably, architecture etc. In my firm, what DevOps department is doing is turning off/reducing the services left right & center, that results in some $ savings in cloud bill. But all that excercise is without even thinking the impact it has on the overall organisation. One big example is that they turned off the debug logs on QA env. Now the bug that we didn't even have to reproduce is now seems impossible to find root cause of. All the testing is now going in a black hole since we can't see what went wrong. But as you know, dev team isn't able to prove their point that in order to save $100 now we are losing thousands of dollars and all delivery and agility went for a toss. In the end? Devops team is getting rewards as they made a nice PPT that has $$ written in the slides.
I think you're amazing at telling people hard truths. I'm not sure hearing this when I was a Junior engineer would have helped though. Sometimes you've got to see it. When I became a manager, I saw how little people care about the parts of the product I worked my hardest on, but how something I think is trivial would help them. It's eye-opening. Kudos to you for making this video!
You highlighted very well the politics of risk avoidance (aka non recognition). This starts from the top down, everybody dodging away from this toxic sth. However, Risk Management is pivotal for mature project delivery. When you have to constantly firefight to get stuff done and deliver projects, there is sth fundamentally wrong.
In my experience, software projects have a much larger volume of issues and risk than many other types of work (I talked about this in another episode on forecasting and commitments). I think this causes people to get overwhelmed and start to shut down. You are correct that in theory people would have the emotional intelligence to know they are going to have to fight against the temptation to write off real problems. In my experience, it's more common that people can't deal with the volume of problems and so we come across negatively. I guess that's where I'm coming from in this episode - trying to help people do the best they can given an imperfect system. There's definitely a balance, and I appreciate your perspective it's perfectly valid.
@@HealthyDev and many are emotionally committed to the project, which is commendable, HOWEVER, may lead to a very toxic (actually toxic) project team incl. all of the antics. Keeping a team together is a real skill and not many project managers/directors can pull this of. I was brpught on a project where I am tasked to be the "glue", advocating for open communication about risk and change. One thing that is clear is... NEVER take ANYTHING personally, even if people try to teach you your job. You just do your thing as intended, but take abort good ideas and stakeholder needs.
@@theaccountant666 oh wow, congratulations to you for pulling that off. I took a contract a few years back where I was hired to be the "glue" as well. I had no idea though until I was deep in it. I would never take that gig again. What they really wanted, was for me to be superman and tolerate the toxic behavior of pretty much all departments in the company. No wonder they needed "glue". They needed a fall guy. Hopefully that wasn't the case for you.
@@HealthyDevThank you. I learnt my lesson a while ago on this very thing. Just walk away from toxicity. They can not pay enough for this kind of BS. Honestly, I got very lucky. The project is very large and quite complex, but also has a human as a PD. However, I also turned down many opportunities that just were not right. I see age as a blessing.
@@theaccountant666 me too. I really struggled with aging during my late 30s, but sitting here approaching 50 I'm coming to much more peace with it. It's helping me to see things a little more neutral. I can totally understand how younger people resist some of the stuff I share, I would have too at their age. Sometimes I feel like I'm shouting into the wind. But if at least 1 person heeds it and it helps them avoid some of my stupidity, it's worth it.
As a manager, this is gold. If you're doing these things I'm actually very likely to leave you alone a lot because I'm confident you're driving everything.
This really hits home. If I bring up some obvious problem that needs to be solved I'm been told "why are you trying to complicate things, let's just go ahead with the project" and when that problem eventually hits I get told "you should think before you do things", and when I tell my manager that I did bring this up I get told "then you should have convinced me we needed to fix this". 😵 I feel like I don't know what they want from me anymore.
I think as an industry we need to get together to start demanding more maturity from managers instead of just keeping our heads down and trying to keep them happy while feeling miserable ourselves. Think about it like this: if this were conventional engineering, would we still want to avoid communicating problems we notice? Would we still want to keep it to ourselves if people didn't do their job? And would we be responsible for reporting status, or would there be a clear plan for building things? We need more training and accountability for managers, which will inevitably also result in improvements to their subordinates.
I don't necessarily see the "reducing your throughput" as a problem of management. It's simply part of the job to try to include unknown unknowns which are more likely to arise in different scenarios. It only really becomes a problem if management starts pushing back on an estimate, at which point I'll be frank and offer to spend time coming up with a more concrete estimate.
I'm really big on making sure I recognize my coworkers contributions. I know how helpful it is for me and I want to spread that around. Nothing feels better than getting kudos for your work, it does so much to combat imposter syndrome.
As a former developer and now manager, i can say you need to translate issues into managerese. I can't use the technical reasons for the delay, and it gets frustrating waiting for someone to explain the intricacies. I need to know: What's the impact on the schedule, your gut feel for how accurate the new estimate is, and one or more alternatives for a descope that could be completed on time. Essentially, i need to know whether I'm going to own the risk or take the bold step of reporting the issue upward, and taking all the management "help" that that entails.
Good point about the "help" above. I don't think people realize how fast things go south if scrutiny starts to creep in. Well worth doing some of the other activities around commitments you describe.
This is why I took a management position. As an engineer for two decades, I've worked under non-technical managers and it wasn't great. I wanted to serve my team better.
On the first point, i had a conversation with a friend a long time ago, where i was complaining. He said something like this: "No one cares if you find tons of problems, our problems are infinite and our time is not, so what are your solutions to the problems you deem most important?" And that really struck me.
you need to do more than you speak. Some people don't even get a chance to show their worth before someone decides to just fire them or quiet cut them in the company. I always think that our hard work should speak for itself in the first place
This is very good advice, that unfortunately I think most of us wish weren't true. A lot of people are attracted to software development because we can apply engineering to fix code problems and we like solving them, unfortunately software development isn't a solo act and we must work with others. People are unfortunately far more flawed and riddled with bugs than code ever could be, and it's important to learn to work around that because if we don't we might cause them to segmentation fault. Even more frustrating is learning that the only person who has authority to fix another person's flaws is the individual themselves, so the only thing the rest of us can do is try to sanitize our own inputs to avoid crashing them.
Holly shit, you said it so well right at the beginning, for mediocre companies it's not about doing things properly, it's all about just looking confident and getting as many tasks as humanly possible in the DONE section, leave the resulting issues to management! hahahah
@@HealthyDev To be honest, my comment is kinda hateful, and completely based on my previous work environment. Yet nontheless true. And I completely agree with your answer, it's human nature, but we can't let that drown good projects and companies.
@@DylanCalaf I hear you. This stuff can be frustrating. I get heated about it sometimes too, I'm trying to get better at it. But I still blow it often.
#2 and #4 are especially huge. #2 means all the other departments will love working with you and your boss will know that you are their first choice of developer to be assigned to their project. #4 means you can over-deliver every time and *still* have time to address all the tech debt and other issues that will make your life easier, but which product, sales, etc. don't care about and wouldn't want to take time away from their projects for. Which means you can deliver more and better more reliably in the future. The others are all good points too. Some of them might seem counter-intuitive to someone new to development, but what you say is actually how it plays out in the real world. Everybody loves the guy who talks about the great work his coworkers did and the shortcuts he found to help the team vs. the guy who is always talking about problems and blame. And despite having Jira and whatever else that clearly communicates where things are and what decisions were made, people are too busy to read through all that, so topping up with quick briefs regularly makes their jobs easier by keeping them on top of things and saving them trouble of digging for it.
Spotting problems is not a skill. Too many people think they are a genius for pointing out what the problems are all the time. Hell, a primary reason you were likely hired is to SOLVE problems (not JUST point them out). Pick your battles, and only raise the important problems once you’ve solved some and gained the trust of your peers and management. You honestly think management doesn’t know about the problems? 😂 The key is PRIORITIZING which problems to address and when. Every business has problems. Choose your battles wisely and your career will prosper. If you have the mindset that all managers are terrible and you are gods gift to tech - your career will continue to suffer. I see so many miserable engineers who would why they never get promoted or make more money. It’s because you are a headache! You put your ego, pride and principles ahead of basic cooperation, communication and tact. Be reasonable, pick your battles, and ship and then watch what happens!
The intro hit me hard. Didn’t get sr this year after getting all positive remarks with the only negative being I needed to show more confidence. I told myself all the same things you called out haha
No need to "reduce your throughput", only reduce your publicly visible throughput. Secretly maintain high levels of throughput, then slowly reveal your outputs over time. Much like the best scriptwriters of television shows extend the release of plotlines over an entire season, using careful timing to build suspense! Sprinkle in some callback jokes, fan service, and clichés/tropes to fill empty space.
RE: Don't highlight problems... This is hard to accept. I'm currently working at a place where the architecture is objectively horrible. Litteraly a multi-million-line code base that could have 80-90% of it's code reduced with basic DRY principals. And this is mostly by design from the lead architect, who desinged each page to bascialy be a seperate applicaiotn onto it's own, with duplicates of the CSS/JS and much of the backend processes and db queries repeated. I'm tempted to suggest to his superiors that the whole application should be rewritten, and let them know that it takes exceedingly long time to make simple changes.
As soon as you said "mostly by design by the lead architect" I think you know the right answer. Have you built so much trust with the architect's superiors by delivering reliably, and being right in the decisions you've made, that they are ready to trust you over the architect? It's not about who's right in that situation (hard lesson, I know) - it's about who's earned the trust.
@@HealthyDev Unfortuately, I've had little to no chance to contribute; in my first 6 months I've modified only a few dozen lines of code. The role was advertised as a developer position but it's turned out more to seem more like a business analyst, atttached to the largest and most problematic customer to fix issues that come up. Most days I do no work outside of meetings; I'm actively looking elsewhere.
Iam in a similar situation and I can tell you simply pointing out he setup a bad architecture to managment is going to get you nowhere. They are going to side with that lead architect. Do suggest concrete solutions that help the project move forward though. Maybe the lead architect will disagree. If so ask about his reasoning. If he doesn't have good reasoning that will expose him. Help and support your teammates. Be the teamplayer. Focus on the positive things you have influence on. This gets you the trust of not only the team members but also management. And lastly changing this, even if succesful, is going to take alot of time. Maybe too much time, if so question yourself do you want to stay here? Is it worth it?
@@HealthyDev, earning the trust is so important. We all want our news and feedback from reliable sources. But fortunately there are leaders (although few) who believe there are no stupid questions, good ideas can come from anyone, etc. It is all about being diplomatic, as well as speaking up if we spot critical bugs, and generally there are many good suggestions also in the comments section of this video. Thanks for talking about this topic. I am a recent subscriber to your channel.
I have coached several people who are neurodivergent and you are correct, they tend to be especially susceptible to doing things that get them in trouble from a visibility standpoint in our industry. My heart goes out to them, and I do what I can to help. But I'm of course not qualified to help them with their underlying challenges there, and I am up front about it.
@@HealthyDev As somebody with ASD I can only say that I have to REALLY HOLD BACK on 90% of the stuff I think and notice during my work and somehow filter and trickle it into meetings etc. I love my job but I can only do it from home fully remote anymore, where I can give myself all the comfort and healthy coping strategies to deal with it all. In an office building I would probably have regular meltdowns nowadays. The way neurodivergent people are handled/treated in tech is quite... desastrous to be honest. I choose to not disclose my disorder to my employer as I have done it in the past and I was either the "token acoustic genius" or immediately put into some kind of "must observe constantly" category and seen as problematic.
@@bassstorm89 I’m sorry to hear what you’re going through. Programming being already a high cognitive load activity combined with the social dynamics must be really difficult for you. Glad to hear you’ve found some strategies that work for you. Those of us who are not struggling with what you are already find it baffling and difficult. Hopefully things go better for you as you discover more strategies.
I wanted to say thank you for this video. For me personally, it's a banger and really hits home. I decided to move to freelancing to deal with all this, but I can see at least some points to practice when I talk to less technical people. With my, hopefully, clients. And also I'd like to add, that developers can relate in a way. Suppose we use some library, or framework or whatnot - and it keeps breaking, reports compilation errors even if we did everything according some tutorial or quick start guide. Or it is poorly documented. We would hate to work with that library even if it's greatly written in our favorite stack. So yeah. Thank you. It took me a while to get to finally watch this video, but I'm happy that I did.
I really need to hear this. Damn near every week. I have always thought that bringing up problems is doing my job properly. And it's gotten me in stuck spots before. It worked well at my first job where I had years of trust built up but it is not working well as a default position when I start new projects with new clients.
Do you remember in the Old Days of NASA launches when they would stop the launch countdown for a Programmed Hold? It infuriated me as a kid "whats that for, everything is OK! why stop the clock???" and I never understood why those were there. Now I'm older and I sure wish I could have baked in some Programmed Hold time to some of the projects I've been on. It would have saved alot of Managment heartburn/untrust when the inevitable "unforeseen problem" cropped up. There needs to be a structured/trusted/accepted way to add that time to a project.
Important topics that maybe some people don't want to hear or think about, but I am glad you address them, as they may make a difference in someone's career.
This video is pure gold and applies to many other aspects of what it means to work and collaborate with people in the workplace. I have this bookmarked for life.
Unfortunately I experienced the same thing. I want to face the problems head on, but it seems like people would rather ignore it and just collect as many checks as possible before SHTF.
Tips reworded in my way Tip 1: Only explain a problem once it has been fixed Tip 2: Tell people what they want to hear by explaining your work in their language Tip 3: Explain the problem, don't blame the problem Tip 4: Account for unforeseen problems when estimating throughput / taking on work Tip 5: Give credit when credit is due
The things you say here might be the norm, but they are far from a requirement. I have worked in companies of differing sizes where this was not the case. The economic pressure is definitely not in favor of such a climate, but that doesn't mean we should accept such toxic working conditions that also demonstrably harm the business. I don't know what the solution is to be honest if someone in the situation doesn't want to play the game. All roads lead to Rome. You can even follow their advice to the letter and still get reprimanded.
I feel for your dilemma. I think people tend to feel this is a binary decision. Either you stick your head in the sand and do good work. Or you play games and that's all you focus on. Really the solution is if you find yourself in a company with systemic issues of trust, and you can't get out right away, you have to do excellent work AND think about the optics of how you proceed. At least that's been my experience.
After 34 years in software as a tester, developer and manager, I can say that you have nailed these issues and what to do about them perfectly. I have been there. If you are just starting out in this field or if you are burning out with frustration and despair, if you do nothing else, listen to this guy and do exactly what he recommends. I also had to learn these things all on my own through very painful experience but they DO work if you follow them scrupulously and without ANY ego.
I've definitely faced this many times. When you notice that a project is going to fail and you voice it, you either get blamed for everything that does go wrong or get accused of "thinking you know it all". I've watched several managers pretend to be surprised when a project fails despite having told them a good 6 months ahead that it would happen and providing them with solutions we could implement in time. The worst is when the manager then gets credit for "coming up" with a solution to salvage the failing project. The same solution offered 6 months earlier. Wanting a project to succeed is often a liability in our industry. "Reduce your throughput" - Definitely advice I wish I received earlier in my career.
![How to sell Digital Products Online WITHOUT AUDIENCE as a Beginner [5 PROVEN STRATEGIES]](http://i.ytimg.com/vi/sLvEwF_b0v4/mqdefault.jpg)
Did you make the mistake of thinking just writing good code is what management really wants? How are you building confidence in you at work?
►► Know your options! Visit my wiki about the top 25 job roles in tech, TechRolepedia → healthysoftwaredeveloper.com/techroles/
There is one flaw with this video though: Everything is presented as if this was always the case, but it's been escalating as computers took over the world.
Every industry has some disconnect between management and workers - the question is, can you step over the pothole or is it ravine?
@@TheExileFox interesting thought.
that was awesome…kinda calling their baby ugly. that’s a sub 💯 lol
@@ItsDeanDavis lol yeah after I used that analogy I wondered if it was a proper choice. Welcome to the channel!
HOW CAN YOU JUSTIFY TELLING A DEV THAT JUST WANTS TO WORK MORE TO GET INTO FUCKING MANAGMENT. How can you sit there and describe the state of development like that without busting out laughing. Our main job is to anonymize accountability and play best buddies? Youre describing a DEI nepo shit hole idiot fest dude. Why would I even want to be born on a planet next to this stuff let alone commit and work on it as if this was value. This is value to a ceo looking to score on indan dev work. Jesus FUCK.
Just remember that most adults are not really adults. They are young children in larger bodies. When you are lucky enough to work with a true adult, treasure it.
I don’t think there is any true adult, only children wise enough to step back and listen before acting.
Nobody knows what they doing, not all the time, some just learned to fumble more gracefully, some learn to learn quicker, needing one or two instead of 5 or 8 attempts. Others simply failed so much they can smell signs of failure a mile away.
Uneventuslly the world simply makes them fear the unknown
That only applies to Americans. Already in the 80s we used to say: "Americans mature until they are 14, after that they just grow taller". The rest of the world is much more reasonable.
My person phrase is: most people have the conflict resolution skills of kindergarten children, except less access to sand and larger vocabulary.
underrated critique of modernity
well my senior used to say "everyone grows old, but only few become wise"
Everything described in this video is more commonly referred to as “Playing the game”. I have often been told “If you want to last at this company, you gotta play the game.”
If you haven't already, check out the episode I did on the first software project in my career. I got screwed over by politics so bad it was incredible. Nobody tells you how the game is played until it's too late. I'm trying to change that, but man people don't want to stare the harsh truth in the face.
ruclips.net/video/d4hFQyuKVhs/видео.html
@@HealthyDev The most important advice imho is the one about leaving the paper trail. This will not only save you politically but also legally in the long run, because any verbal agreement in court is only worth the paper it is written on. I do a similar thing, but in the form of a Jira comment on the ticket, "how we decided in the standup to handle it". Make it a habit.
I would agree that some of it is "playing the game", but that's just what we have to do sometimes!
Playing the game of however destroying the company. Everybody is too afraid to speak up.
@@markusjohansson4949that’s the definition of politics. As Patrick Lencioni says in his incredible book “The 5 Dysfunctions of a Team”. It’s when everyone tells each other what they want to hear - and not the truth.
That’s definitely dysfunctional on a systemic level and different than what I’m advocating here - measured communication of problems. If anyone asks me point blank whether there’s a problem with something I always tell them the truth.
I predicted all of the numerous problems we encountered but my Manager did not want to listen or believe me! Managers have a lot of trouble with that!
Warning management about problems is always a mistake, they will think you are causing it when you end up being right. Rather than preventing it, you are better off preparing a solution and letting the problem happen then fixing it.
@@beowulf_of_wall_st ruclips.net/video/BKorP55Aqvg/видео.html
@@beowulf_of_wall_st "you are causing it"
@@beowulf_of_wall_stThis is dumb because there are some problems you clearly cannot fix. They just don't care about reality and are bad managers. They need to fix themselves instead of me fixing them.
@@beowulf_of_wall_st This is totally counter-culture for me, I'm caring about the customer too much. But on the other hand I totally see no other way as long as it's not my own company...
I hate all the points raised in this video, but most of all I hate the fact that he's completely correct.
Its a sad world we live in where productivity and efficiency are held back by mismanagement.
Thank you. I don’t enjoy having to share this stuff. I do this because I genuinely care for developers. Coaching them is my job. If you heard the stories I do of what people are going through, you’d do the same.
Blaming management without taking your own responsibilities toward it is creating more problems than solving it. As IC, we have way more power in changing things around us than we care to admit, and when we do, we often expect our managers to do it for us. Why do we need a scrum master to change a status update into an effective meeting? Why do we need the PO to wait for the PO to clarify a story? Why waiting for the team manager to write down an onboarding manual for review guidelines?
If you think that the improvement is worth it, then there shouldn't be a problem doing it as part of your role, as long as you don't neglect your priorities.
Who woulda thunk that management destroys efficiency?
When dealing with idiots, you have to be diplomatic, especially if the idiots wield a lot of power over you and pretend you're bending into their dogma. Of course, this can backfire and when the shit hits the fan YOU will be the one getting fired, because they will never take the blame, but that's another story :)
@@theravenousrabbit3671 Not all management is counter-productive, just most.
The "don't highlight problems" is so true and only becomes more true as you move up the management chain. In most businesses, it's better to let a dumpster fire continue to burn rather than be the one that points out the fire. It's not healthy or good for the business but in terms of career advancement, you'll never be rewarded for pointing out problems unless you've already solved them. If you need help or it requires cross-team effort to fix...just don't say anything. The safer path is to let things fail and have enough documentation to prove it wasn't your fault.
Jesus this is why I’m so burned out in IT. What you are saying is true, but for someone that can’t ignore issues, it’s constant stress. It’s also the reason IT systems keep getting less secure and less reliable over time.
You're absolutely correct. I wish it weren't the case, but it's reality. Unless your job is to be actually responsible for the cross-team efforts, trying to take responsibility for them is just setting yourself up for being blamed for things outside your area of control.
@@HealthyDev I learned this lesson the hard way. Dev team ends up being Tier 3 support for everything but nearly 100% of our outages were infra or DB related. I tried to fix them and while those teams were easy to work with and willing to engage, they had skill issues that negatively impacted the business's perception of me when they couldn't execute. Lesson learned the hard way but better to learn it now.
Exactly, positive thinking!
I may be a rookie about this but to me it's just sounds like bad ego of the management/those that are responsible so why should I respect that? If you buy hardware from an external supplier and they don't deliver on time or in the quality they promised, you expect damages, discounts or cancellation too.
I have made this mistake. I predicted a 18 month overrun on the project. I was given a warning letter for "negativity." I told them they were punishing good engineering knowledge.
BTW the project overrun 2 years so I was overly optimistic in fact
Hang in there. “I told you so” rarely gets received well in most companies.
At my former corporation, a Fortune 100 food delivery company, several people who pointed out based on math that the sap conversion would not work.
They were all fired. We were explicitly told that we had to run at the problem fast enough to overcome the hurdles instead of identifying risks and eliminating them. And that we needed to maintain a positive attitude that the conversion would be successful.
After the 10th conversion, they laid off most of the existing IT staff and replace them with infosys. 6 months later the entire conversion failed and they changed to another Consulting Group and rolled back the entire sap conversion and sued sap.
(and they rehired about 20% of those let go at premium rates).
@@macmcleod1188 wow! That's the most extreme example of refusing to accept reality I've heard in a long, long time. Hope you're in a better place now.
@HealthyDev I retired at 51 in 2012. I was extremely lucky. They laid everyone off one day before I was going to give notice. So I got 12 weeks severance instead of the 5 weeks vacation time I was waiting to vest.
But it was pretty bad. My blood pressure was 166 and we had several heart attacks plus one Deloitte consultant in his thirties was taken out unconscious by paramedics and we never saw him again.
In the end, they realize that they really did need big iron and the cloud computing wasn't going to have the processing power they needed. The whole project was supposed to save 100 million dollars per year in salary costs but the cloud computing estimate for a complete conversion was a billion dollars per year.
And the HR department became extremely leaky about facts after the layoffs were announced.
@@HealthyDev the longer version is at 30 I had testicular cancer and had 5 months off work with pay. I realize I didn't get anything out of working at all and I just wanted the money so I started Living on half of what I made and after 21 years, I made my numbers. But the last two years were brutal. I literally slept in my car in the parking lot more than once and we had to work over 80 hours a week several times per month for the last 12 months.
This can be subtitled, "How to survive in a dysfunctional organization." I also see a lot of overlap here with Robert Greene's book "the 50 laws of power." Finding that book opened my eyes to why I was being constantly passed over in promotions at work despite getting positive reviews and completing a reasonable workload.
48 laws of power is a great book for understanding the Machiavellian tendencies in people. And some of my advice does pertain to dealing with it. I hope it's clear I'm trying to advise people to deal with it by using strategies that still help us to be ethical in the face of it though. I don't think we should be employing many of those laws directly as a way to manipulate people. That's just my position of course.
@@HealthyDev A lot of your advice is directly in alignment with many of the laws. Minimize imperfections, praise others, don't outshine the masters, vye for visibility (court attention), etc.
@@Torpidity Sounds a lot like "BE A WHORE".
Corollary: EVERY organization is dysfunctional, because it’s made up of people. Accept it and adapt.
Unfortunately, SO MANY PLACES are very dysfunctional, with most have some dysfunction.
I can't stress enough how accurate and valuable some of these advices are! As a software developer, I often voiced concerns only to be dismissed as negative or naggy. Over time, I learned to play along and celebrate our disastrous projects as if they were brilliant. Ironically, this facade earned me promotions and respect. It's a sad and ridiculous truth.
😂😂😭🤦🏾♂️
Oh gawd, yes to the celebrated dumpster fires 😆🔥
"Elevate Your Coworkers", number one best piece of advice. This is the best "long term gain" technique in my experience, in the short term, it may or may not pay off, but in the long term it always pays off.
As a consultant I started to coach the customer's technical team to present my findings at the end of my gig. This was after one of my earliest gig where the CIO asked me "Why did my people not know this?". This had an effect that I didn't anticipate. From here onward, teams wanted to work with me more because they were learning so much more. A lot of consultants think they walk on water and keeping the information is the secret to the next gig. It's actually the opposite that works best.
"Reduce throughput". That's a tough one to hear but it is very true. I use to "over-produce" and it just bites you in the arse. Management begins to believe every code-change, feature, bug-fix, should be completed in a few days. When I recognized
this, management was asking me to complete mid-size projects in one - two weeks - managers who have ZERO s/w development experience. This is where I began to negotiate lengthier commits to "train management" that writing quality code takes time.
My BIGGEST gripe being a software developer is when someone (Management) with NO s/w experience says, "It's an easy change, right? It's 'just'.....".
You really need to match it to your team; going too slow makes you look incompetent.
@@doughboy_6439 you mean like match their story points per sprint or something? That's a really bad metric. No two story points are the same (you probably know this). On top of that it encourages people to release low quality code to game the numbers.
@@HealthyDev how do you work around that then? How do you not look incompetent and reduce your throughput and commitment?
@@HealthyDev I can be worse than story points. I've worked at places where there was immense focus on what the business can see / feel and no time spent on invisible elements. Sometimes an individual runs around building new features and piling up the tech debt while another team of underappreciated people pay it back down.
I do think most points you make are correct but the extent matters a lot. Many places can handle tech debt in a more mature way. It's like saying there's always bacteria on your food. True but some meals are tasty and others will kill you.
typical sprint cycle at my old job:
> get assigned task for an idea that clearly won't work
> tell boss your boss that an idea won't work
> write an essay why it won't work
> still get assigned the task
It took just 5 years of this for the hair loss to set in
Also: very typical for organizations to have "sprints" that are nothing like actual name-brand Scrum. Like, fundamentally a) your boss isn't part of the Scrum and b) you don't get "assigned" things in the sprint.
I think these things go together a lot. Shops that have "sprints" that are _exactly the same thing_ as two-week deadlines.
I'm only surprised that point 5 wasn't "get blamed when the task didn't work"
@@markw.schumann297that's so true. The point of sprints is to empirically measure the work capacity of a team at a sustainable level, and keep it consistent and predictable. Most managers seem to think that the point of scrum and agile is to increase productivity, while it's actually, and I quote, "maximize the job that is not done".
Story of my life. The time spend on cleaning up the mess afterwards could've been used to implement something that actually works 10 times over...
For the love of god, trust your experts and don't overrule them when they raise issues.
@@ElHipokondriako And that's not self-evidently the goal of every project. I have worked on projects where they *want* to maximize the work for various reasons. That's fine, there are all sorts of business reasons for wanting a project to be bigger in some way. But then you should not be trying to use Agile practices!
What he is describing is basically bad management. Sadly there is too much of it in the software industry. The real problem is that there are not enough managers with over a decade of engineering experience under their belt. This is a symptom of a young industry. Imagine an oil and gas firm, say Chevron, where all the people managing engineers and engineering projects have zero engineering experience. The result would be a disaster, from a safety hazard standpoint and commercially. Maybe it was like that back in the "wild cat" early days of oil and gas, but not now. Look what happens when an established engineering company is managed by non-engineers. I give you Boeing. What happened to the share price this year? ... I am sure you get the point.
You're absolutely correct. I'm suggesting solutions given the imperfect system we all work in. I'm an optimist at heart (believe it or not lol). I've just found sometimes it doesn't help people to sell them on how things could be better if they're suffering right now. Hope that makes sense.
@@HealthyDev Thanks Jamie. Good to know we’re on the same side.
Scroll way down to find this. If you coded well and the management promoted the "confidence" guys instead, that's their problem, not yours. If they didn't encourage you to have work life balance instead of burnout on an overscoped project, that's bad motivator and bad planning. Find the good manager instead of "playing the game", or become the manager yourself and change how it works for others.
The best example, for me, is HP and Carly Fiorina. How the hell did she get that job?
@@vNCAwizard Long story short. She made a lot of decisions which made AT&T money over the short term by cooking the books but neutered them long term. She gave loans to companies to buy equipment off them but somehow removed the loan from the balance sheet so the only thing that showed up was the income off the sales. Billions in loans. When all the loans came due to be paid off by who she gave the money too she was already out the door and at HP. The only thing that saved them was Lucent had so many patents under Bell Labs that AT&T could sell their entire share of the company to others that just wanted the portfolio. Whole thing got swept under the rug in the fallout, otherwise it'd have probably been another Enron.
I've worked on so many projects where something unexpected comes up for any number of reasons. All too often managers yelled at me, called me incompetent, and much more as a result. This was even showing them what the issue was, potential solutions, and decisions that need to be made. As for "Jamie isn't responsible for Operations" - the lazy manager would typically come back and say "well, that's still your problem and you need to work with them to figure it out!"
Thanks for providing an opportunity for me to offer some clarification, this is great feedback. I consider a dependency someone who has ownership for something you're dependent on. If you have to do part of the work with them, you're a collaborator. And absolutely management will hold you accountable if you don't make sure the collaboration happens.
@@HealthyDev Yes - collaboration is important. I've had a couple of managers who refused to help out or otherwise assist with escalation, so I had to much of the leg work myself. Learned a lot from that process.
@@HealthyDevReally depends. If the manager cannot get the side-api team to fix a bug that's blocking you, how can you as a random coder?
My advice is to line up another job. The behaviour of your manager is absolutely unacceptable. You should never accept being a doormat.
@@ForgottenKnight1 Agreed. That's what I did - found a better job and better boss.
I've been a software engineer for 6 years at a Fortune 100 company, a small start up, and then at a FANG company. This video is unreasonably true. The definition of a "good developer" to leadership is one that makes management feel good in that moment. You have to internalize that, you have to go on a journey of discovery to understand what makes the management feel good in this moment, and you to comport yourself to that standard. If you don't you will be punished for it 99% of the time. How much you enjoy working at a company is intrinsically tied up in this. How much your mental health is affected is tied up directly in this. How much your career progresses in the company is directly tied up with this. No amount of personal effort, no amount of beautiful code, knowledge of the best new framework, nor indeed how many LeetCode problems you've solved will ever change this fact.
This is so well said
Top comment. Accurate and can second this. What we think is valuable is not what management want really.
@@MartinoNotts Yeah, the one thing I'll add to this comment is the following: You also have to accept that there are scenarios where management simply cannot get what it wants (often because what it wants is impossible, either due to time constraints or simply reality forbids square circles), and you're the one who will take that beating. And sometimes, it can be a bad, bad beating. These are the moments where you're going to get fucked, management will lose trust in you, and there's often very little that can be done to mitigate the situation, especially once trust is lost. And the sadder reality is that you just have to accept this and move on. It's better to switch companies and start at 0, rather than try to go from -100 to 100 once management has asked you to do the impossible and you've failed to do the impossible as expected. Sad fact of reality, but it's also why 2 year stints at companies is so common. When I was at the FANG company, I was in an unwinnable situation. There was no way management could be happy because their management didn't know what it wanted, leadership at the highest levels was absent, and most importantly what they wanted simply could not be done (and it certainly couldn't be done by hot dropping a bunch of newbies into a politically precarious situation with no 0% support, 100% blame, and 5% credit for any accomplishments). We couldn't move like a start up and wave our magic wands on red-tape and mountains of tech debt, and deal with changing our minds about what we wanted every 6 months.
I wish I had advice or something pithy to say to myself 2.5 years ago when I joined that FANG company, but in all honesty, I've been unemployed for 6 months and am still reeling from burnout.
I've been out of the industry for close to a decade, but I've been thinking about returning. Hearing this video triggered a lot of memories in me that frankly... "make my blood boil". It helps me to realize why bums would rather eat cold expired soup out of a can than go to work.
I love coding, but I hate everything to do with business politics and kissing ass. I refuse to do it. I guess might just have to stand on the side of a freeway off-ramp with a cardboard sign that says, "will code for food".
For me, I have done a lot of this partly due to my autism. I communicate directly. I don't naturally see hierarchy. I point out issues and problems in the code, standards, processes, etc. I don't know how many times I'm told "Well, no one else is bringing this up." I even try to relate my behavior back to company standards (which as one might guess, doesn't go over well). It's really hard for me to see value in doing anything but direct communication and it's exhausting to "mask" all day at work.
I am thankfully working now for a company that encourages neurodivergent people and I've had managers take a different look at how I present myself when it comes to these things. There's still some on the business side that aren't always ok with it, but when they see the results I deliver they usually accept it since the results I deliver for them make them look good.
There is always room for improvement for sure, but I'm glad companies are becoming more aware that for people on the spectrum, this is who we are and we don't do these things to be abrasive or confrontational.
this is ultimately why i want to be self-employed, i can't stand neurotypical bs.
Appreciate your perspective here. You may consider letting folks know upfront your intentions. Also, keep in mind that your PRIMARY job is not to point out problems. Every business on the planet has problems. Lots and lots of problems. That’s why engineers and managers are hired: to SOLVE the problems. Focus on prioritizing and solving problems. Pick your battles.
Amen brother.
These are good tips but always apply them In balance. I've seen people super successful at playing this game for a year or so until they got let go with adjacent reasons: "Not delivering enough", "Not highlighting problems early enough", "Not ambitious enough - cause they are not committing to enough things" and even: "Lack of leadership material" because of the fact that they were not specifying which dependencies were acting as blockers.
Those are all real problems. I said not to state the person specifically responsible for a blocker, not to avoid raising it at all. Unscrupulous people can use any excuse in the book to justify letting someone go, so at the end of the day there are no guarantees. I'm just trying to offer some practical tips that will increase the likelihood that you don't do something that gets you looked at negatively that could be avoided. Hope that makes sense.
@@HealthyDev Yeah, reasons are sometimes made up. I've once heard "acting weird" but there was no answer for "Could you please provide me some examples, so that I could work on that?". And the question was not in the context of negotiating to stay, I just genuinly wanted to know what was that "weird" behaviour. I believe it was getting sick for a month though.
I guess this happens when you have knowledgable and capable superiors. So I guess it really depends on the individual organizations.
Oh man, it's like you have done this video for me. I'm really getting frustrated with my management not seeing value in what I do, the several languages and technologies I have to juggle with, the problems I communicate.
Hang in there. I hope this year you can find some ways to let go a little bit and focus only on what you can actually control. Easier said than done, I know.
@@HealthyDev 🙏
@@HealthyDev Wise words no matter your field. I work in hardware development but many of your videos still apply.
@@erikyoung5139 good to hear. Yeah I figured some of this is just corporate culture advice, couched in situations programmers understand best.
Systems engineer here. Yep... it's for us all. We deal with this kind of constant nonsense all day long. all over the industry. It's not just in programming and development.
Actually, I have been warned about a toxic culture in US companies. Allegedly, there is a usual "game" in big tech where the middle management tries to attack the messenger (the one who reports issues in their deliveries) and downplay the issue, while at the same time their engineers are already secretly working on a fix; when the downplaying works then the fix is released secretly, and if not (and the issue is escalated to higher management) then there is a good chance that they can present themselves as those who found a solution "just overnight".
My understanding from talking to them is this is just as prevalent in Indian companies.
Correct, these things are all signs of bad management with a poor attitude. They don't trust engineers because they essentially look down on them.
Don't worry, German management got you covered as well ;)!
I recently figured out that people don't like being told their ideas are bad. When assessing risk or disagreeing with a topic, I found it better to ask questions addressing your concerns and essentially place confidence in their statement on them. I.e. "you have revealed the risks and are willing to pay the price of the fallout". I'm still trying to practice this in my day to day job, but it essentially is a game changer when dealing with leadership, especially upper management such as directors.
GREAT strategy.
I had to do something similar at my last job, where I'd worked for 14 years, and I despised it.
Having to ask genuinely stupid questions in order to gradually lead my boss by the hand like a baby to what the problem with his plan was, all because if I just said what the problem was and what the solution was he'd always take it as an attack on his person and would respond with a counter-attack. He couldn't stand anyone ever saying that his plans weren't perfect.
This was for even the smallest detail, like an issue in scheduling, work flow, or a mistake in a set of instructions for the workplace, and it only got worse when he got closer to and eventually passed retirement age.
@@DefaultFlame well done. There are so few people that understand how effective this is in the right situations.
@@HealthyDev Was it effective? Sure.
Did it, along with a multitude of other issues with my boss, lead to me having four mental breakdowns in a year, wanting to self-delete, quitting my job, and currently being unemployed and on antidepressants? Yup.
@@DefaultFlame oh man. I'm sorry that sounds horrendous. I had some personal issues going on that contributed to my mental problems and depression. But yes work was a huge part of it.
Yes, the advice is healthy for a career, but some of it is toxic for delivering value. At the end of the day, my job is to deliver value to a customer: that the customer hands over money and doesn't sue us is the only thing.
I hear you. Unfortunately you can’t deliver value if you’re not trusted because you’re unaware of the optics of how your work impacts other people. That’s my intention here. Delivering value is the goal. Often it’s being done in an imperfect system.
@@HealthyDev this is true. As a minority developer, you find this out alot sooner which enabled me to see this and adjust for it. Gaining trust is absolutely essential and it's easier to understand human nature than to be a purist, you may never find a "perfect" place for that.
'Document verbal decisions' was one of those I had to learn the hard way - how many of us have spent hours grinding, grinding, grinding, only to be told later "that's not what I said" - AWFUL!
'Elevate your coworkers' is something I've been doing more of, and it has definitely shown results. It's hard because our industry tends to be sort of individualistic and competitive, so it feels like you are going against the grain, but I think teams thrive when they can know 'when to compete' vs 'when to compliment'
I actually got fired over one of those verbal decisions that didn't get documented. The guy actually using the feature said they wanted this automated email feature to work one way, so I did it that way, and then months later I got a performance review that said I screwed up that feature. What was actually wanted was never documented anywhere either, but I got all the blame for it.
Also try to do prototyping and let the Product Owners see how it's going to work early. Then they can say that's not what was meant and have them rewrite the ACs. Also change ACs with the permission of the PO and suggest ACs in a text.
Documenting is still not a bulletproof solution. A manager can still claim that the conclusion you wrote in the email was overruled in a later meeting or that he said otherwise once at your desk. In the end, it's you against the person who pays you, and it's a matter of how hard you're willing to oppose this person to prove your claim.
An old saying is "if you surface a problem, also propose one or more solutions."
It's a bad saying because not all known problems have a known solution. If they would have, they would have been solved, making them a problem no more.
@ForgottenKnight1, all problems have a solution. If you include time passing, it's no longer relevant. 😂
@@ForgottenKnight1 Not all problems are worth solving.
@@ForgottenKnight1 It goes back to the "The customer is always right[.]" quote. Everyone seems to forget the engineering process and skips from [issue] to [done] rather than brainstorm to discuss ideas before coming to any possible solution.
@@drno87 Those wouldn't be actual problems then, real problems need to be solved
Man ... 2.1 spoke really hard to me. I was fired from a company with the largest database in the US (probationary period) because I was raising a whole bunch of security issues to management about vulnerabilities in their software and their processes. I was asked to leave at the end of my first week.
Their incompetence will come to bite them in the ass one day.
Man! I’m so sorry. Security is one of the only aspects of software development I would think that point does NOT apply to. Fear can make people do crazy things…
And unfortunately this attitude is very common at companies. If you let them know about potential problems they call you negative, a troublemaker, bringing down morale and various other sorts of nonsense.
Been in this industry for nearly 20 years. I can't agreed more.
- have a solution before you present the problem
- record all verbal decisions
Great advice, especially the second one. I have inadvertently been saved by doing the second one, just by coincidence of me preferring to communicate in written/typed form, from some scary situations that I had been directly involved in.
A good developer tries to understand a problem well before trying to find a solution. But this is not how managers are usually thinking. They don't want to hear much about problems, they want solutions.
All true, but then they could attack us about our time, when did we have time to think about the problem and the solution? We should have been doing something else.
@@ReneHartmannofc not, they are like brats that like having everything handed to them. They are not used to think much.
@@andrejszasz2816 If the problem was something about the product or the company, they are dumb. Just. Dumb. And the shouldn't be managing anything anymore.
The magic words: "Put it in email."
I 100% use some of these tips quite a bit. Especially when communicating to management about a question, or concern you have. Always, EVERY TIME reiterate your concerns by email after your talk with management. This is incredibly helpful when you have a manager who is either incapable of accepting responsibility for a mistake, or the type to always deny everything. In my line of work its called "Cover your ass." I could not tell you how many times a written account of a meeting has saved my skin over the years.
I think the biggest problem that we have with management and bosses in general is that they do not have the time, or energy to fully understand the work of the people they supervise. They only see a small section of it and forget about the iceberg effect. 10% of your work is highly visible to your supervisors, while they in general have little to no idea about the other 90%.
The absolutely random guitar solo at 7:40 really caught me by surprise
This was a super useful video. I definitely often struggle with status updates because the problems I'm working on can be so specific that I'd have to provide a huge amount of context. I really like the point about highlighting other people's achievements. I do that with my friends all the time and it does absolute wonders, I should do it more in work. It sounds absolutely worth it to use the time gained from reducing your throughput to do things like writing status updates, crediting people and building team morale. Spending time building morale is the sort of thing that is very easy to sacrifice when in a rush, but you're right that it pays huge dividends in the long term for both you and the team / company.
Absolutely. I'm getting too many comments that people think I'm saying to just do these things I recommend and then not do any work. It's not an either/or thing. It's totally possible to do both as long as we account for it in how we estimate and commit.
Once upon a time, as a newcomer to a project, I wrote a document describing 40+ problems and their proposed solutions. The team acknowledged it and even thanked me for "bringing it to their attention". But nobody did anything. In the end, it was I who fixed all those problems in the course of year and a half.
Understanding the problem is half the battle won. When you have people under you, perhaps you can communicate what you need from them to solve these problems. But most of the time, I think it is healthier for the team to just work on solving problems they find. Difficult to develop this culture but so far my teams that I have managed work this way. We do our best in our roles and we seek to fix the problems we see. Even if the rest of the world doesn't. We complain like it is a sport but we enjoy each other's company.
lucky you, I got fired for describing the 30+ problems.. the head of the branch did not want to change the obvious problems and having someone point out those problems put his competence on the line.. which transformed into a big target on my back! what a terrible company that was
@@o1-preview hmm sounds like you dodged a bullet of a company.
But I think you should have just fixed the problems and then if they still did not accept it, then leave.
Undermining the trust people have of the people around you will not help the team unfortunately. I'm sure you've had times you went back and realised what you've built was not the most efficient or may have been over engineered. But that was the best decision you could make at that point of time.
I'm sure there will be people that appreciate the thought that went to it, but you wouldn't want those decisions to affect the trust that people have in you. Especially if 100s of people need to trust you to make a decision in order for the project to continue smoothly.
Did it benefit you in least when completed though?
@@o1-preview You dodged a bullet - an incompetent and insecure manager making the workplace a mined field
This is so heartbreaking to watch, but I can see how it's all true, and why I didn't get the promotion I wanted at my last job. Thank you for spelling it out - the cynical view is that corporations are lying through their teeth about what they want. The compassionate view is that they don't *know* what they want. Thanks for peeling back the curtain and showing us how we can *actually* get ahead when our technical skills aren't what's holding us back.
I have a huge problem with overcommitment. Then I get burnt out and quit. I've always been afraid that if I promise less and deliver less, I'll get fired or "be the weakest link" - but working as hard as I can and putting in overtime hasn't been helping me get ahead either.
Overcommitment was my calling card the first 15 years of my career. It's OK, we all learn at different times. I still have to practice setting better and more realistic boundaries.
Thanks for speaking up! This is some awesome actionable advice that I wish I had been given at the start of my career. Also these are unspoken rules that no one ever says out-loud because it would make them look bad, but you NEED to know them if you don't want people to make an enemy out of you in less than 3 months time.
Even if I learned some of those points the hard (and long) way, I still find extremely hard to cope with the fact that most of those problems exist only because in the business world people are way more often concerned by the way they look like than figuring what's best for the project and the company they are working for.
I’m right there with you. This wasn’t a fun video to make, in that I knew it would possibly raise visibility of some negative aspects of work culture. Ultimately I hope it helps people keep their job and the confidence of people that care too much about appearances, which turn out to be many of them.
@@HealthyDev Don't worry, your video is very useful. Knowing the truth is valuable especially when it is ugly. It took me about 20 years to realize some of those painful points.
Now I probably need two more decades to accept it.
@@Marcus_613 definitely. I’m still struggling to accept it everyday!
This x 100
Developers do it too.
I’m not an IT-related Engineer, and all the recommendations you provided apply 100% to my role, and completely align with my own personal experience.
You probably already know this, but you still chose to direct this to just programmers, because you don’t want to make assumptions, and you are cautious and humble about your own knowledge and wisdom. This actually says a lot about you as a person and the level of consciousness you have developed.
I subscribed.
Welcome to the channel!
oh boy that's hard advices. it makes the work place a little grim. Like, tech company are not following the scientific code of ethics, management just want to hear good news. thanks for your insigth, i feel less naive. Awesome content ! and nice guitar :
Thanks! Humans in general like to say we're virtuous and ethical, then do whatever is self serving in reality. As soon as you can embrace this, things get a lot easier. I choose not to play dirty like many do (did a video about this a few weeks back). But I also have just accepted you're going to run into bad actors.
Top best video you made. Important to be authentic, but be aware of interactions with people. Sometimes you forgot the rules and this was a good thorough freshup of things you can forget when busy in the project. Thanks!
Thanks! I only learned this stuff by doing it so wrong, so many times first...
Dang! Everything you say I can so relate. In the past I took on the role of being an all-in-one IT guy (e.g. IT and network support and Software Developer). I never had to deal with most of the things you talk about until now. Great stuff man, keep up the good work!
Thank you! So if I understand correctly you were a "one man IT guy" and now you're on a team, running into some of these issues? That makes sense. It's a very different experience on a team, for sure. Hopefully you're adapting to it OK.
Speaking about communicating problems and doubt: I had one colleague on my team who was pointing out a ton of problems and pushed them relentlessly through to the end, without mincing his words much. He got on bad terms with the project manager. He eventually quit the team because he saw no end, and management wasn't working with him since they saw him as getting too personal about it (which honestly he did). The second was a 30 year senior dev. He saw the first one and commented that that guy was trying to change too much at once, and that with his own experience, he learnt that you can only push so far. Well... they're not prolonging his contract because he spent the year also getting animated and pissed about all the different issues in the project.
Both of these absolutely dominated the refinements with by far the most questions, sensing large problems ahead or demanding a huge amount of answers while complaining that the user stories are half-baked.
It does feel like the project lead and management eventually got rid of them and surround themselves with anyone who finds these guys annoying.
Thanks for sharing, that's an excellent real life story to drive home the points I'm making in this episode. I talked about this in another episode since this one, that some people seemed to take this video as an "all or nothing". Meaning you either don't care about how you're perceived at all, or if you do you're just an "ass kisser". The truth (in my experience) lies somewhere between.
You are doing a tremendous service to people in our industry! Thank you!!
You're too kind. Thank you!
My last role was Delivery Manager. Around me, I saw nontechnical sales people making half of the money, nontechnical managers causing the worst problems, and the facade of “confidence” winning over good engineering.
I decided to pivot back to engineering roles, seek engineering-driven cultures and managers. Many companies have predatory products and selfish cultures. Don’t drink the cool-aid.
Mastery should precede management. I’m focused on data engineering. I’m a data plumber. If that means leading scrum or putting on a product manager hat because folks are looking to me for architecture, prioritization, structure, or mentorship, I’m game.
But domain mastery is my focus, and the leaders I respect most are masters of their crafts first and managers maybe fourth. That’s my new paradigm.
So basically we need to do the managers job for them, prioritize problems and solve the critical ones, all while telling management everything is going according to their schedule, then when it all falls over, make sure you can prove it wasn't your fault.
If you go back and listen to point one (which I believe you’re referring to) you do want to make management aware of issues but in a patient, incremental way. Hope that makes sense.
@@HealthyDev Ah, I see. So we actually babysit them as well as doing their job for them.
@@gunt-her if you consider having patience babysitting.
@@HealthyDev I mean I've been blessed with good managers pretty much my whole life, but some of the stories I've heard it sounds like they cause more problems than they solve.
You could definitely package shit nicely and with a ribbon. You are absolutely right about the difference between our perception of ourselves snd company’s perception of what value we bring.
I retrained to became a developer after almost 20 years, of which a decade was as a people manager and stalk holder on projects. Unfortunately this is mostly true, but I can say with confidence this is mostly a symptom of bad management rather than the way it should be. And it is not just an issue in software.
It is a frustrating reality that we need to "play the game" until you are promoted to a position where you can actually implement changes, but at that point it no longer benefits them (and may even hinder the own management targets).
I would say these issues are more prevalent in US based company cultures in my experience, and some European businesses have been a lot better; however it more usually comes down to the relationships you build with individuals around you. When those good people leave, it is almost always time to start looking too.
all management is bad management
Networking consultant for 7 years here, can fully understand and agree. Item i woult add in my profession: You have to determine, if the mangement wants actual security (and/or HA) or only on paper. Makes a huge difference when it comes to ressources needed for system + process integration. (Test environments are basically no topic since the hardware (+suscriptions) are insane expensive.)
I learned real quick early in my career that the work I do doesn’t matter. Relationships with coworkers and upholding an “image” will get you further in your career much faster
I wouldn't personally go so far as to say that the work doesn't matter. But yes, doing good work with zero concern for how your image is conveyed is probably not a smart move.
I agree that a good skill is being diplomatic about how you make criticisms or explain technical complexity to the corporate overlords.
But I also think that needs to be STRONGLY counterbalanced with honesty. I see a lot of devs who either avoid saying anything or just outright lie about things to make management and other devs happy.
That is shortsighted in my opinion and while it does initially inspire confidence, months later when the problems they concealed come out, it erodes overall trust.
Being diplomatic, getting them in a receptive mode, presenting the findings as being for the collective good (although with a mature management it may also payoff for personal good, but most likely it may cause personal harm) is the way to go. I would not hesitate in presenting critical bugs, even though I have lost one job for the same.
And it happens at home too. The spouse/parent saying don’t think negatively.
Thanks for your feedback. My intention with this episode is definitely not to lie or be dishonest. If you watch any of my other episodes I'm constantly calling people to higher ethical standards even if it makes them look bad. When we overcommunicate problems or doubt, I don't think this is being more honest. It's not respecting that people have real thresholds of how much negativity they can handle. When we act like we can just spout endless problems (no matter how valid) and people should just "deal with it", we're not being sensitive to human nature. That's just been my experience.
@HealthyDev I get that too. And I wasn't advocating for the person who is just brutally honest and calls out everyone's mistakes all the time. That is exasperating.
The thing is, I think that person, the quiet ones and the yes men all have a common trait, which is an attitude of superiority and a lack of trust and respect for other people.
And I agree with your point that we need to show confidence in our work. One of my weak points has been a tendency to overshare about my own struggles which does sometimes lead to a decrease in the confidence other people have in my work (especially from that guy who loves to call out everyone else's mistakes).
All I am saying is that it needs a balance. We need to be able to be honest while still building a healthy rapport with our coworkers.
@@darthkreggles3798thanks for elaborating. That makes perfect sense. Appreciate your perspective!
That's inevitably what happens. You can't know how much is too much or when is too soon to raise concerns, so people eventually just keep quiet and make sure nothing can get blamed on them.
I am a manager and have some coders reporting to me. The thing that people have to realize is that there is set budget, priority, deliverables, timelines, and client relationships that all have to be considered in context with these problems that are being brought up. It's a delicate balancing act and there's no such thing as perfection. There is such a thing as an "iron triangle". Let's say I do want to fix some of these issues that are being brought up, I may need to go get funding first to be able to do that. And before that I need to deliver on certain commitments that have been made. Management isn't about having absolute control, It's about achieving balance between multiple competing factors.
Yes, but... If you literally force all coders to shortcut many business rules, so that in fact data becomes randomly inconsistent, in many different ways because each client has other settings... You eventually will burn out those who have to do the support with 200% effort from 6AM to 22PM, each ticket being an emergency
Management is also about transparency, if your team isn't aware of what you have to do to make things happen, you can't expect someone just to assume or realize this out of the blue. Communication is key to get everyone aligned.
Most devs will understand all your dependencies towards other teams, clients, upper-management or budget etc. The usual problem is, that devs are treated in a "need-to-know" fashion about these things. Include them as much as possible in the whole process or at least offer it to them repeatedly. It will decrease friction and increase developer happiness.
In an ideal world sure. In reality devs have the least leverage, the client has the most and the company in between.
It's not about leverage, it's about making sure everyone is on the same page so you can collaborate effectively.
Thank you for this wonderful lecture. I am working at my office for 4 years and I did some bad mistakes. But over the time I realize that I need to overcome these situation and move forward with my career. This lecture just clarify what I actually need to do. Lastly THANK YOU so much. Love it.
You're so welcome! I've made everyone one of these mistakes myself (sometimes many times). Hang in there.
Great video mate, I've worked in software QA for 7yrs, so worked pretty closely with devs, you're spot on and great advice, keep it up :-)
These ring so true. I’m at that phase in my career as a senior software engineer where I’ve learned that I’m on the autism spectrum (shocker, a software engineer on the autism spectrum). All the weird problems that arise from my communication with most other people are finally making sense (particularly communication with managers). I’d realized a couple of these, but not quite as well fleshed out. Many thanks for the clarity.
Wooow this video was shot at the right time, I am precisely at this moment in my career. We are starting a new project and we failed and lost a client using the methods they are using now. I been voicing a lot lately and. it was all in a bid to get architecture better. Been in a meeting with management and the CEO approved a solution I provided but I think I lost some peers to the solution. Given I am fulltime frontend I think I been telling backend to up their API games a little, I may have got me some less friendly peers based off it yet all I was trying to gun for was a smoother way for the project to actually have life.
So much familiar. Reporting problems itself can be a problem. I hate most of managers in ordinary company, too. Good managers let subordinates feel safe but yours were different I guess.
In my case, I went with "fix before reporting and make a mountain of (solved) problem reports" and "produce fuckton more" to annoy with my managers. In every company, executives picked me up then chairman picked me up and tasked me with something very secret to realize their goal. My advice is "be confident. do not hesitate. solve problems as many as possible". Other developers who are slow and quiet won't last long. They are there to drag you down. Ignore them. Under such an environment filled with cowards, you can go as far as you think you can go.
What I have noticed for a long period is that in any gacet of life the one that is hated the most is good people, people that speak the truth and people that actually wants to make things work, they're seen as negative people and they're suffered the most
When you shine a light in darkness there’s a lot of impetus for those who don’t want their flaws to be revealed to exercise power covering it up.
Noticed the same.
Really good points. This resonated with me big time. I used to worry about problems that weren't my own all the time.
Ultimately gaining the perspective that I can share the burden with others and continue on with my own duties is what led me to salvation.
Also a healthy amount of uncertainty in my own worries, that theres a high chance it wont be a problem.
Other people aren't in my head. When they evaluate my productivity, they measure it by what I am supposed to be doing and accomplishing, not based on whether or not I'm completely content and at peace with what I'm doing and how I'm doing it.
From a burgerking burger flipper perspective, your manager evaluates you by being on time, and being dependable in your burger flipping duties. The manager doesn't care if you found some neat way to make the burgers tastier or theoretically safer. That isn't your job, and you will be evaluated on performing your job.
Yeah but if you are told to cook burgers with a piece of glass instead of the flat top grill....
One big issue with softwares is that its damn difficult to quantify almost any aspect of it. Be it security, maintainably, architecture etc.
In my firm, what DevOps department is doing is turning off/reducing the services left right & center, that results in some $ savings in cloud bill.
But all that excercise is without even thinking the impact it has on the overall organisation.
One big example is that they turned off the debug logs on QA env. Now the bug that we didn't even have to reproduce is now seems impossible to find root cause of. All the testing is now going in a black hole since we can't see what went wrong.
But as you know, dev team isn't able to prove their point that in order to save $100 now we are losing thousands of dollars and all delivery and agility went for a toss.
In the end? Devops team is getting rewards as they made a nice PPT that has $$ written in the slides.
I think you're amazing at telling people hard truths. I'm not sure hearing this when I was a Junior engineer would have helped though. Sometimes you've got to see it.
When I became a manager, I saw how little people care about the parts of the product I worked my hardest on, but how something I think is trivial would help them. It's eye-opening.
Kudos to you for making this video!
You're very welcome. I'm not sure how much I would have listened either...
You highlighted very well the politics of risk avoidance (aka non recognition).
This starts from the top down, everybody dodging away from this toxic sth.
However, Risk Management is pivotal for mature project delivery.
When you have to constantly firefight to get stuff done and deliver projects, there is sth fundamentally wrong.
In my experience, software projects have a much larger volume of issues and risk than many other types of work (I talked about this in another episode on forecasting and commitments). I think this causes people to get overwhelmed and start to shut down. You are correct that in theory people would have the emotional intelligence to know they are going to have to fight against the temptation to write off real problems. In my experience, it's more common that people can't deal with the volume of problems and so we come across negatively. I guess that's where I'm coming from in this episode - trying to help people do the best they can given an imperfect system. There's definitely a balance, and I appreciate your perspective it's perfectly valid.
@@HealthyDev and many are emotionally committed to the project, which is commendable, HOWEVER, may lead to a very toxic (actually toxic) project team incl. all of the antics.
Keeping a team together is a real skill and not many project managers/directors can pull this of.
I was brpught on a project where I am tasked to be the "glue", advocating for open communication about risk and change.
One thing that is clear is... NEVER take ANYTHING personally, even if people try to teach you your job. You just do your thing as intended, but take abort good ideas and stakeholder needs.
@@theaccountant666 oh wow, congratulations to you for pulling that off. I took a contract a few years back where I was hired to be the "glue" as well. I had no idea though until I was deep in it. I would never take that gig again. What they really wanted, was for me to be superman and tolerate the toxic behavior of pretty much all departments in the company. No wonder they needed "glue". They needed a fall guy. Hopefully that wasn't the case for you.
@@HealthyDevThank you.
I learnt my lesson a while ago on this very thing.
Just walk away from toxicity. They can not pay enough for this kind of BS.
Honestly, I got very lucky.
The project is very large and quite complex, but also has a human as a PD.
However, I also turned down many opportunities that just were not right.
I see age as a blessing.
@@theaccountant666 me too. I really struggled with aging during my late 30s, but sitting here approaching 50 I'm coming to much more peace with it. It's helping me to see things a little more neutral. I can totally understand how younger people resist some of the stuff I share, I would have too at their age. Sometimes I feel like I'm shouting into the wind. But if at least 1 person heeds it and it helps them avoid some of my stupidity, it's worth it.
As a manager, this is gold. If you're doing these things I'm actually very likely to leave you alone a lot because I'm confident you're driving everything.
I have over 25 years of dev experience. This guy is spitting 100% facts!
This really hits home. If I bring up some obvious problem that needs to be solved I'm been told "why are you trying to complicate things, let's just go ahead with the project" and when that problem eventually hits I get told "you should think before you do things", and when I tell my manager that I did bring this up I get told "then you should have convinced me we needed to fix this". 😵 I feel like I don't know what they want from me anymore.
My wife and I are both in tech, but not programmers... all of this advice is still completely relevant to our positions.
Good to hear!
I think as an industry we need to get together to start demanding more maturity from managers instead of just keeping our heads down and trying to keep them happy while feeling miserable ourselves. Think about it like this: if this were conventional engineering, would we still want to avoid communicating problems we notice? Would we still want to keep it to ourselves if people didn't do their job? And would we be responsible for reporting status, or would there be a clear plan for building things? We need more training and accountability for managers, which will inevitably also result in improvements to their subordinates.
I'm not so sure it's any better in other engineering fields, unfortunately. Much of this is just the nature of management and relationships.
I don't necessarily see the "reducing your throughput" as a problem of management. It's simply part of the job to try to include unknown unknowns which are more likely to arise in different scenarios. It only really becomes a problem if management starts pushing back on an estimate, at which point I'll be frank and offer to spend time coming up with a more concrete estimate.
I'm really big on making sure I recognize my coworkers contributions. I know how helpful it is for me and I want to spread that around. Nothing feels better than getting kudos for your work, it does so much to combat imposter syndrome.
As a former developer and now manager, i can say you need to translate issues into managerese. I can't use the technical reasons for the delay, and it gets frustrating waiting for someone to explain the intricacies. I need to know: What's the impact on the schedule, your gut feel for how accurate the new estimate is, and one or more alternatives for a descope that could be completed on time. Essentially, i need to know whether I'm going to own the risk or take the bold step of reporting the issue upward, and taking all the management "help" that that entails.
Good point about the "help" above. I don't think people realize how fast things go south if scrutiny starts to creep in. Well worth doing some of the other activities around commitments you describe.
This is why I took a management position. As an engineer for two decades, I've worked under non-technical managers and it wasn't great. I wanted to serve my team better.
On the first point, i had a conversation with a friend a long time ago, where i was complaining. He said something like this:
"No one cares if you find tons of problems, our problems are infinite and our time is not, so what are your solutions to the problems you deem most important?"
And that really struck me.
So if you see a problem but don't have a solution you should not mention it at all?
you need to do more than you speak. Some people don't even get a chance to show their worth before someone decides to just fire them or quiet cut them in the company. I always think that our hard work should speak for itself in the first place
This is very good advice, that unfortunately I think most of us wish weren't true. A lot of people are attracted to software development because we can apply engineering to fix code problems and we like solving them, unfortunately software development isn't a solo act and we must work with others. People are unfortunately far more flawed and riddled with bugs than code ever could be, and it's important to learn to work around that because if we don't we might cause them to segmentation fault. Even more frustrating is learning that the only person who has authority to fix another person's flaws is the individual themselves, so the only thing the rest of us can do is try to sanitize our own inputs to avoid crashing them.
Holly shit, you said it so well right at the beginning, for mediocre companies it's not about doing things properly, it's all about just looking confident and getting as many tasks as humanly possible in the DONE section, leave the resulting issues to management! hahahah
The majority of companies in our industry are what you'd call "mediocre". Some departments of FAANGs are not exempt either. This is just human nature!
@@HealthyDev To be honest, my comment is kinda hateful, and completely based on my previous work environment.
Yet nontheless true. And I completely agree with your answer, it's human nature, but we can't let that drown good projects and companies.
@@DylanCalaf I hear you. This stuff can be frustrating. I get heated about it sometimes too, I'm trying to get better at it. But I still blow it often.
#2 and #4 are especially huge. #2 means all the other departments will love working with you and your boss will know that you are their first choice of developer to be assigned to their project. #4 means you can over-deliver every time and *still* have time to address all the tech debt and other issues that will make your life easier, but which product, sales, etc. don't care about and wouldn't want to take time away from their projects for. Which means you can deliver more and better more reliably in the future.
The others are all good points too. Some of them might seem counter-intuitive to someone new to development, but what you say is actually how it plays out in the real world. Everybody loves the guy who talks about the great work his coworkers did and the shortcuts he found to help the team vs. the guy who is always talking about problems and blame. And despite having Jira and whatever else that clearly communicates where things are and what decisions were made, people are too busy to read through all that, so topping up with quick briefs regularly makes their jobs easier by keeping them on top of things and saving them trouble of digging for it.
Spotting problems is not a skill. Too many people think they are a genius for pointing out what the problems are all the time. Hell, a primary reason you were likely hired is to SOLVE problems (not JUST point them out). Pick your battles, and only raise the important problems once you’ve solved some and gained the trust of your peers and management. You honestly think management doesn’t know about the problems? 😂 The key is PRIORITIZING which problems to address and when. Every business has problems. Choose your battles wisely and your career will prosper.
If you have the mindset that all managers are terrible and you are gods gift to tech - your career will continue to suffer. I see so many miserable engineers who would why they never get promoted or make more money. It’s because you are a headache! You put your ego, pride and principles ahead of basic cooperation, communication and tact. Be reasonable, pick your battles, and ship and then watch what happens!
The intro hit me hard. Didn’t get sr this year after getting all positive remarks with the only negative being I needed to show more confidence. I told myself all the same things you called out haha
We’ve all been there, myself included. Keep going. You’ve got this!
This was such a very practical career advice, thanks so so much.
Reporting problems is super touchy, and that's a very good point. Just that can be a 2h video. Who to talk to, when, how, why...
13:46 this is all the real job
It’s way more talky-talky than typey-typey
AAA plus content. You made me see through the management's lens. IT veteran here, and boy, did I learn. Thank you so much.
Glad I could help! Thanks for the feedback. 👍
0:25 And that's why I have chronic impostor syndrome
No need to "reduce your throughput", only reduce your publicly visible throughput. Secretly maintain high levels of throughput, then slowly reveal your outputs over time.
Much like the best scriptwriters of television shows extend the release of plotlines over an entire season, using careful timing to build suspense!
Sprinkle in some callback jokes, fan service, and clichés/tropes to fill empty space.
RE: Don't highlight problems...
This is hard to accept. I'm currently working at a place where the architecture is objectively horrible. Litteraly a multi-million-line code base that could have 80-90% of it's code reduced with basic DRY principals. And this is mostly by design from the lead architect, who desinged each page to bascialy be a seperate applicaiotn onto it's own, with duplicates of the CSS/JS and much of the backend processes and db queries repeated. I'm tempted to suggest to his superiors that the whole application should be rewritten, and let them know that it takes exceedingly long time to make simple changes.
As soon as you said "mostly by design by the lead architect" I think you know the right answer. Have you built so much trust with the architect's superiors by delivering reliably, and being right in the decisions you've made, that they are ready to trust you over the architect? It's not about who's right in that situation (hard lesson, I know) - it's about who's earned the trust.
@@HealthyDev Unfortuately, I've had little to no chance to contribute; in my first 6 months I've modified only a few dozen lines of code. The role was advertised as a developer position but it's turned out more to seem more like a business analyst, atttached to the largest and most problematic customer to fix issues that come up. Most days I do no work outside of meetings; I'm actively looking elsewhere.
Iam in a similar situation and I can tell you simply pointing out he setup a bad architecture to managment is going to get you nowhere. They are going to side with that lead architect.
Do suggest concrete solutions that help the project move forward though. Maybe the lead architect will disagree. If so ask about his reasoning. If he doesn't have good reasoning that will expose him.
Help and support your teammates. Be the teamplayer. Focus on the positive things you have influence on. This gets you the trust of not only the team members but also management.
And lastly changing this, even if succesful, is going to take alot of time. Maybe too much time, if so question yourself do you want to stay here? Is it worth it?
@@HealthyDev, earning the trust is so important. We all want our news and feedback from reliable sources. But fortunately there are leaders (although few) who believe there are no stupid questions, good ideas can come from anyone, etc.
It is all about being diplomatic, as well as speaking up if we spot critical bugs, and generally there are many good suggestions also in the comments section of this video. Thanks for talking about this topic. I am a recent subscriber to your channel.
@uvideo100 welcome to the channel! Appreciate your participation and insights.
Great content. If I end up with a difficult manager, I hope to remember some of these points.
2:25 oh boy. I think a lot of programmers would struggle with that. Especially when so many are neuro atypical, and brutal honesty is a key trait.
I have coached several people who are neurodivergent and you are correct, they tend to be especially susceptible to doing things that get them in trouble from a visibility standpoint in our industry. My heart goes out to them, and I do what I can to help. But I'm of course not qualified to help them with their underlying challenges there, and I am up front about it.
@@HealthyDev As somebody with ASD I can only say that I have to REALLY HOLD BACK on 90% of the stuff I think and notice during my work and somehow filter and trickle it into meetings etc. I love my job but I can only do it from home fully remote anymore, where I can give myself all the comfort and healthy coping strategies to deal with it all. In an office building I would probably have regular meltdowns nowadays. The way neurodivergent people are handled/treated in tech is quite... desastrous to be honest. I choose to not disclose my disorder to my employer as I have done it in the past and I was either the "token acoustic genius" or immediately put into some kind of "must observe constantly" category and seen as problematic.
@@bassstorm89 I’m sorry to hear what you’re going through. Programming being already a high cognitive load activity combined with the social dynamics must be really difficult for you. Glad to hear you’ve found some strategies that work for you. Those of us who are not struggling with what you are already find it baffling and difficult. Hopefully things go better for you as you discover more strategies.
I wanted to say thank you for this video. For me personally, it's a banger and really hits home.
I decided to move to freelancing to deal with all this, but I can see at least some points to practice when I talk to less technical people. With my, hopefully, clients.
And also I'd like to add, that developers can relate in a way. Suppose we use some library, or framework or whatnot - and it keeps breaking, reports compilation errors even if we did everything according some tutorial or quick start guide. Or it is poorly documented. We would hate to work with that library even if it's greatly written in our favorite stack.
So yeah. Thank you. It took me a while to get to finally watch this video, but I'm happy that I did.
Corporate culture 101
yeah
The pain of knowing all this is true, and I had to learn it the hard way, was made better by that beautiful G&L of yours :)
Thank you Jayme. This was just what I needed to hear today.
Amazing advices and I love the guitar riffs interlude!
Wow this is such a valuable perspective. Tysm
I really need to hear this. Damn near every week.
I have always thought that bringing up problems is doing my job properly. And it's gotten me in stuck spots before. It worked well at my first job where I had years of trust built up but it is not working well as a default position when I start new projects with new clients.
Do you remember in the Old Days of NASA launches when they would stop the launch countdown for a Programmed Hold? It infuriated me as a kid "whats that for, everything is OK! why stop the clock???" and I never understood why those were there. Now I'm older and I sure wish I could have baked in some Programmed Hold time to some of the projects I've been on. It would have saved alot of Managment heartburn/untrust when the inevitable "unforeseen problem" cropped up. There needs to be a structured/trusted/accepted way to add that time to a project.
Well that's supposed to the PR review process, but usually product just wants you to go go go!
Important topics that maybe some people don't want to hear or think about, but I am glad you address them, as they may make a difference in someone's career.
Exactly what went through my mind when I recorded it…thank you!
This video is pure gold and applies to many other aspects of what it means to work and collaborate with people in the workplace. I have this bookmarked for life.
Gem of a video and wealth of information.
Exactly what I’ve experienced.
Thanks and keep up the great work!
This has me rethinking so many things that have happened. Makes more sense now. Thanks for posting.
Hopefully you don't lose your hope in humanity, like some people feel this video has done.
Unfortunately I experienced the same thing. I want to face the problems head on, but it seems like people would rather ignore it and just collect as many checks as possible before SHTF.
Yep
Tips reworded in my way
Tip 1: Only explain a problem once it has been fixed
Tip 2: Tell people what they want to hear by explaining your work in their language
Tip 3: Explain the problem, don't blame the problem
Tip 4: Account for unforeseen problems when estimating throughput / taking on work
Tip 5: Give credit when credit is due
Tip 1 and 2 you may benefit from listening to again, but I think you nailed the others.
The things you say here might be the norm, but they are far from a requirement. I have worked in companies of differing sizes where this was not the case. The economic pressure is definitely not in favor of such a climate, but that doesn't mean we should accept such toxic working conditions that also demonstrably harm the business.
I don't know what the solution is to be honest if someone in the situation doesn't want to play the game. All roads lead to Rome. You can even follow their advice to the letter and still get reprimanded.
I feel for your dilemma. I think people tend to feel this is a binary decision. Either you stick your head in the sand and do good work. Or you play games and that's all you focus on. Really the solution is if you find yourself in a company with systemic issues of trust, and you can't get out right away, you have to do excellent work AND think about the optics of how you proceed. At least that's been my experience.
After 34 years in software as a tester, developer and manager, I can say that you have nailed these issues and what to do about them perfectly. I have been there. If you are just starting out in this field or if you are burning out with frustration and despair, if you do nothing else, listen to this guy and do exactly what he recommends. I also had to learn these things all on my own through very painful experience but they DO work if you follow them scrupulously and without ANY ego.
best tech video that I needed 10 years ago
I've definitely faced this many times. When you notice that a project is going to fail and you voice it, you either get blamed for everything that does go wrong or get accused of "thinking you know it all". I've watched several managers pretend to be surprised when a project fails despite having told them a good 6 months ahead that it would happen and providing them with solutions we could implement in time. The worst is when the manager then gets credit for "coming up" with a solution to salvage the failing project. The same solution offered 6 months earlier.
Wanting a project to succeed is often a liability in our industry.
"Reduce your throughput" - Definitely advice I wish I received earlier in my career.