1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier.
2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around.
You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit.
Or you can just start your own company and make your own rules.
1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process.
2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge.
That said, I agree that it was better for him to leave.
Well, he sucked in that team. It's good to know the kind of person you are. I've learned, somewhat the hard way, that I become a bit of a nightmare in situations where I can't make a difference quickly. This tends to lead me away from very large, very process-driven, very political organisations, because I simply don't have the temperament for it, and towards smaller, scrappier companies, where it's possible to make forward progress quickly.
One day, after all, I will die. I don't want to have spent too much time between now and then having to deal with torrents of organisational bullshit. The fact that I don't know how much time I have left only adds impetus to cut through the nonsense.
Whereas some people can survive, and indeed thrive, in that kind of environment. They have the patience to see it through, and gain their satisfaction in other ways than merely seeing the product taking shape quickly.
> Well, I AM actually stubborn!! But if the metrics had shown that BATCH was worse, I would absolutely be the first to change my mind.
He's self-critical. I also think he's only right about being stubborn in its original meaning (untameable) rather than the new colour the word seems to have (unwilling to change despite evidence).
What happened here was an NHL player joined a team thinking it was another major league team, but it wasn't even college ice. That's fine, but his mistake was not just leaving for a different team. If you come into a team thats slightly beneath you you can raise it up to your level and change peoples careers / lives for the better, but getting too far off just doesn't work. You're way too ahead of them and you're new so they don't trust you or want to listen to you. Just move on to a more pro project.
At the end of the day, if you do want to provide technical leadership, the skills to understand the team and how to interact with them effectively are at least as important as the technical skills.
So sometimes I have to kindly remind myself that its current state isn't indicative of some damning (yet oddly egotistical) personal failure, where I "shoulda" rewritten everything from scratch by now.
On the plus side, the QA team is gradually learning to do more than manual browser tests...
There's something about the writing style on that page too. Hard to describe.
(I'm totally kidding; your question is an excellent one.)
What's funny to me is how sometimes there are two qualities -- being both more competent (than one's peers) and not liked -- that in combination can further perceptions that someone "isn't a team player"..in the eyes of The Majority, the same people who are the real problem.
If the team says pigs can fly, the sky is red and Bob isn't a team player, all of those things might as well be true. After all, perception is reality.
The author was also smarter before he was empathetic. When he saw someone become touched after the criticism he put forth, he should have changed pace. And changed focus. Instead of focusing on the critiques, he could have focused on the outlying problems contributing to those critiques.
Instead of ignoring the responses everyone made to good suggestions, he could have been more accepting and started to beat the same drum.
Point is to find common ground first. Solutions come second.
This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above:
> Or you can just start your own company and make your own rules.
When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that.
In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them.
If they are total assholes, you don't want to work there anyway.
But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.
Being alpha geek and able to code well doesn't correlate at all with the kind of management and people skills required to run a team. There's a ton of Daily WTF as examples of team "leaders" who are great coders but cannot communicate at all.
The standard MBA solution for this situation is the "surgeon model" used by medical teams. The tech lead makes all the technical decisions, but there's a team leader or manager who makes all the leadership decisions, and does the "people stuff".
That "people stuff" totally includes firing team members who the technical lead doesn't like, for whatever reason.
my mba program emphasized that (1) effective teams can be built from a diverse variety of people and organized in many different ways, and (2) the effectiveness of the team rests on trust and honest communication between team members (technical skill is rarely the limiting factor of a team).
Also worth pointing out: Sometimes (often) the people who are most vocal about this are not the best coders :-)
This is a fundamental insight that a lot of people don’t seem to get. I always refer to this quote to drive home the same point: “There is no such thing as a dysfunctional system, because every system is perfectly aligned to achieve the results it currently gets.”
If you want to be likeable among imbeciles, then you have to emulate one. When in Rome and all that.
Honestly, I don't think this is true in the general case. It's certainly true that there are times when deadlines mean code quality is going to suffer, but I think the incidence of this is probably lower than the frequency with which this is used as an excuse.
*I'm aware that DK doesn't really say what the common interpretation says it does
Next biggest issue is a changing team. If you don't really understand some bit of code it's often safer to code around it than mess with it.
Perhaps the founder had better things for his time than perfecting some code that was already good enough to get clients/VC money.
But continuing to ignore code quality (and potential security issues) and blindly piling on complexity and feature creep and hoping for the best is just playing Russian roulette with your money.
It's a "nice problem to have" kind of thing.
Just you would like for people to assume you have the best intentions and reasonable practices, you should also provide some respect to the developers of the original code and not assume what you see in production is necessarily their best work or the way they would do things now.
Now I just put a mental crosshair on the code I want changed and come back to it.
The number of times I've spotted some terrible bit of code then go through the version control system to try to find out more of why that moron did what he did only to discover that I wrote the code is embarrassingly large.
It’s the delusion that hurts.
Nobody is going to schedule time for integrity on the project roadmap. That's not how integrity works. You can find some or lose some, but on any given day you have it or you don't.
When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory.
You pingpng around and when you find the problem you can’t remember why you were looking for it.
Then there’s code where you say “ugh”, take a breath and keep going.
If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues.
That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.
In the long run ugly lines of code are so much better than a broken architecture or too much coupling.
My new motto is: filter out the reversible decisions and worry about the rest. When something in the former set breaks, make it a teachable moment.
At my current job, the quality of the codebase is frankly, quite shit. The unit testing coverage is fine, but the actual quality of the code isn't good. It's not clean, there's a lack of separation of concerns, it's poorly formatted.
Within the first week of starting the job, I had a laundry list of things that we should do to clean up the codebase. However, I've been slowly feeding this list to my manager, rather than just dumping it on him.
- It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus"
- the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap."
The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."
So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.
And then you understand that you weren't wrong, and the opportunity for improvement is there, when time is available, but you haven't risked alienating people by treating them as if they're idiots for writing imperfect code.
Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it.
It's our job as developers to explain the importance of unit tests, and why they're non-negotiable.
Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).
Let me put on a hat that I wore a few times - someone who had one person above him in a company. I will also preface this with 'I hate sloppy code. I hate shortcuts. I want people to spend time on building tooling instead of writing features. If I could wave a magic wand we would have 99% test coverage'.
This is 100% incorrect. Code quality on a list of priorities for the business is somewhere between the taste of a three day old coffee and a french fry that fell off a tray.
Business is there to make money. It means that code that works somehow is better than perfect code which did not happen to ship because developers are still working on the unit tests. Developer time costs money. Operations people time costs money. Anything that does not make money but costs money gets de-prioritized. If you think that "code smell" and "unit tests" are non-negotiable especially if it is at the cost of tweaking/fixing something that is going to generate revenue, you are drawing a line in a sand and I'm going to have to point you at the door.
If you would like to get me to allocate resources ( read: $$ ) to address code smell/code stench/etc, you need to either convince me that the sky is falling ( i.e. we start losing money/we are going to start losing customers ) or you need to give me something that can offset some of my costs or you need to come up with a clever way to enable us to make more money.
> Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).
Exactly. The "right time" may not be now and may not be before. It may also not been for another year.
P.S. Incidentally, this is also why product people/project managers and sales people get a better seat at the table than developers ( which is a mistake, from my perspective ) - they typically talk about money while developers talk about code.
I don't see how you can expect more than "if we don't do it, we'll eventually have problems." Customers might leave and features will get harder to implement. It all costs money, but how much is very difficult to say.
Let me ask you this - if your car mechanic told you that you need to overhaul your entire car because he did not like the way it felt to him would you let him do it?
Having worked on legacy code bases with version control you start to see patterns. While there are definitely those decisions made because they were required at the time there are also definitely those individuals who obviously were out of their depth or were willing to "hack it" to get it to work. And a lot of times, they are lauded as being "A+ top producers" when the reality was they just did it faster than everyone else because they didn't think about long-term quality.
The story version, I see in terms of manufacturing. If I was working with a parts supplier and asked for them to deliver a part I needed. The requirement was as fast as they could do it. They make good on the delivery. From a business perspective everything is great. We're making sales and we met our deadlines. The supplier was great in helping us out. Suddenly three years into our five year warranty parts from the supplier start failing (performance problems and fragile releases). It becomes obvious there's a major quality problem in the parts that were manufactured. We talk to the parts supplier but they've gone insolvent (the software engineer left the company). Suddenly we need to hire a new parts supplier (a new software engineer with years of experience) to rush the replacement parts that are required to meet our warranty. Which, (hopefully) having learned our lesson are paying the higher rate (proper compensation and reasonable time for quality) to guarantee a quality replacement part to prevent the loss of profits of another round of extended warranty replacements. At this point the company has just cost itself both monetarily and potentially in reputation by making the original decision to fast-track production to "get to market".
I recognize that the scenario above isn't software. It's a physical thing that's gone out into the world out of the control of the company that created it. But fundamentally the same trade-off of "deliver it now" vs "deliver it right" is made. And often made by people who don't never consider the long-term costs (technical debt) because "that's not now, that's in the future". And people will often rationalize their decisions in these situations. The often spoken:
"That happens to other companies, we'll be successful."
Lack of understanding
"I don't care about the outcome, we need it now."
"John said we could do it, so we're doing it."
"We'll deal with it once we have slack time."
People need to stop saying this.
It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups.
The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things.
Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules".
I wasn't. My runway would have been about 10,000x shorter than his.
Whats the fallacy for when you think you've identified a fallacy and simply assert it? Just because someone writes down the definition of a fallacy doesn't make it true. A dog has four legs and a tail, but its not a cat. Sorry, the fallacy thing is a pet peeve :P
Anyway, back the to topic. I do believe, you missed the central point and latched onto a tangential irrelevant point. The point is identifying the company culture, understanding peoples personalities, their motivations, and then figuring out a way to work together - even if you have an annoying boss, even if your coworkers are incompetent (as they often are), even if you think you know how to fix all problems - is WAY more important than doing something because you think youre hot shit who can prove people wrong.
>The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things.
>Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules".
Okay, but that is not the only way people start companies. SV is its own bubble, when you can funnily enough, become a multimillionaire without turning a single dollar in profit. In the real world people put their savings/health/marriage/family life/ on the line and sacrifice a LOT to start a company.
>Anyway, back the to topic. I do believe, you missed the central point and latched onto a tangential irrelevant point. The point is identifying the company culture, understanding peoples personalities, their motivations, and then figuring out a way to work together - even if you have an annoying boss, even if your coworkers are incompetent (as they often are), even if you think you know how to fix all problems - is WAY more important than doing something because you think youre hot shit who can prove people wrong.
There are a few people saying that. Nonetheless, I do believe that there are a number of people on this thread who are happy to use that as an excuse to say "shut the fuck up and kiss the ring" (e.g. the guy who said 'wait six months before proposing anything new'). That isn't healthy either, a and if you work with people like that the healthiest response is to leave and try and find somebody who isn't a jerk to work for.
>Okay, but that is not the only way people start companies.
I didn't say it was. Nonetheless, the most common unifying feature of entrepreneurs isn't a propensity to be trailblazers who take risks - it's access to spare cash, and, shockingly, not every employee of every company has capital just lying around.
If we're talking probabilities, the average entrepreneur is more like my boss than Mark Zuckerberg.
Bosses like to feel that their authority is deserved though, and it's easier to think that if you spread the myth that just "anybody" can start a company.
>That isn't healthy either, a and if you work with people like that the healthiest response is to leave and try and find somebody who isn't a jerk to work for.
That is a weak point though. The alternative explanation to that is that they didn't actually mean what you think they meant.
It is very tedious to say "wait six months before proposing anything new - but be polite and ask questions, don't be a pushover, don't agree to unethical decisions, don't be a jerk, etc, etc" People often use shorthand to convey their strongest point.
>If we're talking probabilities, the average entrepreneur is more like my boss than Mark Zuckerberg.
If you're talking about finances - totally disagree on that one. There are FAR more small businesses funded by small loans or borrowing from your savings or family, and grinding it out, than being handed million dollar VC cookies. That's my own feeling based on businesses around me (I'm not in SV)
Some quick data that I pulled: https://www.treasury.gov/resource-center/tax-policy/tax-anal...
Less than 5% of small business owners are millionaires.
> can run a profitable 7-11
Which is anything but the kind of business where you "make your own rules." 7-11s are a type of business known as a "franchise". To get an idea what that means, just see the company's FAQ :
> 7‑Eleven provides a fully stocked, turnkey operation [...] obtains and bears the ongoing cost of the land, building and store equipment [...] pays for the water, sewer, gas and electric utilities [...] pays for any building rent and real estate taxes [...] provides financing for all store-operating expenses [...] provides bookkeeping, bill paying and payroll services for store operations [...] provides a support structure and business consultant who meets with the Franchisee weekly to help maximize store performance.
TLDR: It's not a relevant example because it isn't the kind of empowerment (or risk) we're talking about.
Not really in charge of much if they do that are they?
True, but in addition to that and I guess more important is to get the mandate to do that from the upper management. Make that mandate a part of your job role. Then whether the team likes it or not, truly respects you or not, an official mandate makes it doable.
The other side is while for very practical reasons teams create all kinds of debt to move forward, we also tend to settle into a working mode using the adage of don't fix if not broken, which can be very expensive if you need to scale or pivot, and this just does not apply to start ups. Most big companies that sink I think is because they have created all sorts of invisible debts and there are people who might have fixed it, but their passion not backed by a mandate never lets it get fixed!
This is a symptom of an entrenched workforce and quite a red flag.
Juniors have to prove themselves - other should not: that's what interviews, CVs and experience are for.
No, it's a sign that many domains are full of hidden constraints and pitfalls. For example, it's easy to nit-pick a distributed storage system (such as the author seemed to be working with) as too slow and complex, until you actually learn about the consistency/recovery/etc. corner cases that make a simplistic "just do this" proposals non-viable. You could say that's a failure to document the requirements or design. You could also say that people shouldn't need to document things that are considered baseline knowledge in their domain, and that maybe you do need to show some understanding of the complexity before you seek to do away with it (cf. Chesterton's Fence).
And I've also seen great coders dissolve before my eyes (in the face of personal problems) and turn into very poor performers that routinely caused short and long term technical problems.
I don't think you just need to earn respect when you join an org - I think you need to deserve the respect you earn, and work to maintain it.
I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.
A developer took the time to review the existing code, and point out things that could be improved upon. That's part of our job. Even if you don't want to make any changes, or he's wrong about some of the feedback, you should be grateful to him/her.
How much revenue your code is earning says nothing about the quality of the code. That you feel the need to mention it says something about your ego.
It does say something. In this case, it might be saying that, for this particular application, the quality of code is simply not that important.
Maybe the technical debt should be reduced, saving the company money down the road by reduced maintenance costs and reduced issues as development continues.
Maybe the code is feature complete and there's no reason to change what works. It has technical debt, but perhaps the business calculation is that there's not enough benefit to cleaning it up (and in fact messing with working code may introduce issues.)
Either way you look at it, how much revenue it produces doesn't enter into the calculation.
Now you might say the revenue is so low that the code brings little value to the company and so the technical debt doesn't matter. But again that's looking at the wrong thing. Even if it brings in zero revenue, as long as development is ongoing because it brings some other form of value to the company, then the technical debt matters. The right things to look at are the costs involved in cleaning up the technical debt, vs the costs of continuing on while ignoring it. It's all about weighing costs and not about revenue.
But it doesn't matter to this particular decision which is weighing one cost (technical debt) against another cost (fixing said debt.) There is no revenue in the calculation at all to consider, just costs.
It says everything it needs to say. Revenue pays developer salaries.
No, believe it or not some people prefer dignity.
>The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it.
Whether it had $300,000 or 10M revenue, doesn't change the fact that it might had 300 things wrong.
Not to mention that a single thing done wrong could still result on some large embarrassing outage, customer data exposure or deletion, etc, and result in costs/fines worse then those $300,000.
("Yeah, I've made millions out of this web service, who cares that I store customer credit card details in plain text").
>I have dozens of applications in production
Any specific names, so we can avoid them?
The European Union. If you have any of their residents in that database, then you have about 3 weeks to fix that...
In which case you can continue not to care.
Nobody ever ran a successful business on dignity.
It might be true that nobody ever made a hugely profitable business on dignity.
But it's absolutely false that that aren't businesses that are successful with dignity.
So, depends on your definition of success.
If it is "supports me and my workers and can even moderately grow and produce good stuff for my customers" then many did.
If it is "I want to eat the world like Uber" perhaps no one die.
This is beyond ridiculous and you're creating a hostile environment for your developers. It'll come back and bite you in the future.
I do understand it though, and when you're fresh in a project it's easy to go for the low hanging fruit like that. But, be subtle about it, ask if it's welcome, that kinda thing.
When you start work with a new codebase you spend some time to get acquainted with it. It only makes sense to take notes of bugs or possible improvements when you do it. A pair of fresh eyes will always find improvements to be made.
If you expect me to take on a project without looking at the previous code then you're simply a fool.
It would've made me reconsider the job I currently have. Upon saying that, I am enjoying the challenge of trying to eliminate as much tech debt as possible.
But being in leadership and spending time around a few hundred coders over the hears has taught me the value of someone who does this.
I hope this wasn't the reason the person was fired, because it's a missed opportunity for management: someone with that kind of drive and commitment to quality is valuable to have - and hard to find. I can count with my hands the number of developers with that kind of drive I've found.
With no further context - meaning: I'm making a lot of assumptions here - I think I'd've helped them schedule time to evaluate these opportunities for improvement (how much do they cost to fix? how much will they cost if not fixed? How can we prevent this from getting in new code? etc.), and when the numbers are right - schedule time for fixing them, too.
If non-agreeableness was their sole defect - it could've been worked on over time. That's what leaders are there for: to help their collaborators grow.
dafuq is that? The more eyes on a piece of code, the better.
Grandparent = the parent of the parent.
is that dozens of apps supporting one business, or dozens of businesses?
Plus 2000 lines > $300K - I think you beat Pieter "Think of the Frameworks" Levels - https://twitter.com/levelsio/status/938707166508154880?lang=...
One of the best advices I've heard about starting a new job is that, shut up for 6 months and just do whatever you're told. Don't make any decisions, don't make any improvements to the company process, and don't argue with people. Be relentlessly curious and ask lots of questions and follow the herd. Learn everythig you can about the process - the pitfalls, who are the strongest and weakest teamates, who are the difficult ones, who are the influential ones, how do they resolve issues.
Once you learn the team's in and out, you have more leg to stand on when influencing decisions. That's when you start suggesting improvements, drawing on the solid experience and trust you've built over the past 6 months
From your story, it's clear you wanted to "do it my way" from the get-go and had no patience or respect for other people's way of doing things. It has nothing to do with like-ability or being right and certainly shows lack of professional experience and judgement. I would certainly not want someone like that on my team, no matter how technically gifted they are because an asshole player like that would derail any software team
I've found it better if I don't shut up, I tend to ask a lot of questions. I still do what I'm told (that's what I'm getting paid for, ultimately), but the chance to ask questions is one that shouldn't be passed up.
The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?"
And, ultimately, every company is kind of fucked up. Each company is fucked up in a slightly different way. Accept this as your starting point, try and figure out why it's fucked up (your first 6 months), and then try and fix it by working with your co-workers (who, despite working at a kind of fucked up company are probably at or above the median for human intelligence).
Absolutely. Ask questions, all the questions. Just be smart about it. There will be time later to discuss these things, and the company will have reasons. If the reasons are ones you can't live with, get out, but you're not in a position to affect real change at this point. But for me when a junior dev is asking questions, it tells me they are actually invested.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
Bad habits are contagious, momentum gets lost. Conformity is a strong force.
I've been lucky to have great leadership to learn from and model, and who've taken time to guide me through why things couldn't be fixed at a certain point in time - or plain asked for patience and scheduled time to devote to my concerns.
Given good developers are pretty much in demand, I think we can afford to stay true to ourselves most of the time and just shop around for leadership that suits our style.
Size of the team is important as well. The example I gave was 3 other people on the team. Building a relationship with 3 people doesn't take a huge amount of time. But how about an engineering organization of 4 teams and 20 people? Well, now that's going to take quite a bit longer. It's also going to be more difficult and complicated as navigating multiple teams, initiatives, interests is obviously an order of magnitude more complexity than one team and 3 people.
I like this one. I see a lot of contractors come in and write code that doesn't fit with the rest of the code base. They don't make any attempt to understand why we are doing things a certain way. I know there is plenty room for improvement but first make an effort to understand the current situation and only then make suggestions for improvement.
I'm in such a situation now. A large rambling app that shouldn't be an app, written in a spaghetti style. Ever more features compounded by a boundless bug list, growing daily. All addressed by too small a team, clutching at 'agile' to make some measurable headway. But its a forced march into a gale, and losing ground all the time.
Contractors were supposed to come onboard to help retool and redesign. But got roped into bug lists and creeping features and daily standup meetings that take 45 minutes. Work is evaluated solely by 'momentum' and tickets closed and other futile things.
So we all turn, turn, turn the crank, because crank-turning resembles work and we're getting paid.
Six months are just about up! So what should I do next? Say something now? To whom? These guys are all marching in formation off the cliff, and have no bandwidth to entertain philosophical discussions about the nature of gravity and the sharpness of the rocks at the bottom.
A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability.
If you are good you can make improvements in the worst code base without having to change everything first.
Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.
But buggy code in an elaborate, overheated pile is not the same as 'shitty code'. Its doing all the wrong things and going nowhere.
Another cost analysis includes 'opportunity cost', the good that you could be doing instead of massaging the dinosaur this product has become. By that measure, work done on this 'product' is money down the drain.
I've fixed megabytes of bad code in my day. If it was just a matter of code preferences, then sure I'd agree. But this thing is irresponsibly put together. So much drama to do so little, that 'fixing bugs' in it is really just moving them around.
If this isn't what you signed up for and have other options, provide the customer of your intent to end the engagement when you have satisfied the term of the contract at 6 months (don't do it early, just give whatever notice is needed so you can end it on time). Don't assume that anyone there cares about your ideas on how to fix things or they would have asked you already.
One big caveat: if you're going through a 3rd party contracting company I've got some bad news for you... you probably never were there for the strategic work but rather to be a warm body to sit there and be billable so just put in your notice and move on. Worst case, you get offered more money to keep putting up with it (make sure it's a real increase... I'd go for at least 15-25%)... and if that appeals to you, enjoy some easy money riding it out for a bit longer.
And yeah 'rate' at a large corporation is an intractable thing. My contracting company (I'm a partner) is billing through another contracting company, which is billing thru a billing company, which is contracting the client. The deal was, take this rate or take another job.
Which means, I've been looking constantly for another gig of this length or better. Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.
The company agreed to (or set) your rate, they set the assignments, you've done due diligence in informing them of higher level issues, you have nothing to feel guilty about.
Things often have to hit some minima low point for larger changes to be considered. Hopefully they'll still have to resources to stay afloat while the change is enacted... but personally there may be little point waiting around for it unless you see an opening to where you can help at a higher level (and at a higher rate) and they're willing to accept it.
The other half of the time:
* You are just wrong.
* The issue is already known to everyone but it has been deemed low priority.
* Things may seem wrong but they are that way for a reason.
So, pay attention, make a mental note of issues, but don't bring anything up in the first few weeks, as you may look at best silly, at worst, like a whiner.
I disagree. Do these things, just do them in a subtle manner.
Nobody likes someone who comes to a new job and can't stop saying "at my old job we did XYZ in such a way". It's annoying and condescending.
Nothing wrong with hinting at improvements though. Trivial example: rather than "we should all be using rubocop", you could mention in passing that rubocop really helps you write clean code.
If I can explain our refactoring/internal improvements road map, and give brief backstory about why the current state is the current state, and save someone weeks or months of "ugh is this code really the best thing we could be doing here?!" context-less fumbling, that's a great tradeoff.
I suppose it could backfire, if [new hire] immediately disagrees with my reasoning and comes to the conclusion that I'm just an idiot who's bad at that stuff, but is that really going to be worse to hash out some on day 3 instead of day 40? If [new hire] turns out to be an asshole who isn't open to other people's opinions, let me find that out ASAP.
Author seems somewhat arrogant, one of the worst personality traits in my opinion. Hard to be liked if you're arrogant.
2. If it's one person that you have a problem with, there is a possibility that they are the problem. With two,the probability decreases a bit. With three or more people, the probability goes the other way round - you are probably the problem.
3. Watch 'Jiro dreams of sushi'. The cook took several years before he was allowed to bake a simple cake. It is not just a matter of knowledge, skill or even passion. It's being accustomed to the environment, being useful in some area to the business and making meaningful contribution before other nice things materialize. You still need a lot of skills, passion, talent and work ethic; but those are not the only things.
Kudos to the author in spotting a blindspot. However the tone of the articld still left me wondering if they actually still felt that they were better than the rest or if they realized their limitations.
Teams reach a kind of stable state. New hires may well represent a desire of the firm to change that stable state. The team may not be on board. Sandbagging is not so uncommon.
In this particular story, the review situation is what particularly raised flags for me. Obviously the author did not situate himself well, but I'm not sure he'd have been happy if he had been more adaptable, and that may be on the team and not him.
The same is true of anything else. Sometimes the whole team is totally wrong, and their way of doing things is detrimental to the overall goals of the company.
Well, yes actually, you are. By what mechanism does a group of clansmen become one notch less destructive? Certainly not by having newcomers tell them non-whites are equal.
They become less harmful by A) feeling like they have the institutional support to take care of their own, so they have less need to lash out, B) having safe, passive exposure to The Other, and C) having people they trust question their worst ideas.
If you’re not making some similar constructive move, then yes: you’re part of the problem.
Notice that we’re not saying you’re wrong. Of course speaking out against white supremacy is right, that’s a separate question from whether it’s problem or solution.
It’s easy to be correct while contributing nothing to solving a problem.
The dirty secret of software development is that the vast majority of it is done very suboptimally. Both in terms of time taken, and the approach taken to solve the problem. A technically skilled engineer is able to spot these shortcomings and improve on them. A politically skilled engineer is able to get buy-in from the rest of the team, in order to make things better. A well functioning organisation is one where the talents of the technically-but-not-politically skilled engineers, are harnessed to their fullest extent. Not as a favor done to that engineer, but because it helps the organisation itself.
From reading the story, it's clear that this team is even less technically competent than others. It's also clear that the author is very technically skilled, but not politically skilled. Unfortunately for him, the organisation isn't highly functional either, likely stemming from its very political team lead.
In such situations, you essentially have one of two choices. Quit and look for a better team. Or stay, accept that you're working with a bunch of dunces, and do the best you can while getting along and collecting your paycheck.
I can relate because I found myself in a similar situation at a previous job, with almost the exact same quarrels and frustrations. Luckily for me, my team lead was much less political and more open to outside suggestions. Because of this, I was able to ram-through what I thought was the right solution, even though I was constantly butting heads with others. Looking back, I realise how lucky I was to have an open-minded non-political team lead, and how rare that actually is.
If a civil engineer came to a team building a bridge and noticed everyone was building something dangerous, he MUST say something or people will die. Imagine a world where the rest of the team poo poo's him for "not getting along."
There is an old joke that after an interview you should ask 3 questions:
1) can she do the job
2) can you work with her
3) is she an axe murderer
OP can certainly satisfy one of these criteria but even if they’re okay on (3) not meeting (2) is enough for exclusion.
When you find yourself in a toxic (from your perspective) situation you really only have 2 options. If you decide to stay you have to make the best of the situation and get on with people.
It sounds like OP responded to this situation in a way that probably wasn’t in line with this thinking. It’s all well and good being “right” but such accomplishments are marred quite a bit of you’ve annoyed everybody around you in the process.
I’m speaking as somebody who has been through this cycle a few times and finally settled on “getting on with people” vs “being right” after I got the feeling I'd changed job a few too many times.
The transition in this way of thinking was actually quite painful and I made many slip-ups whereupon people would presume I had slipped back to my old ways and couldn’t change - the scorn still rings in my ears. But eventually I did and now I’m one of those effusive hackers that gets on with people, and just drops into tricky situations as they arise. A highly prized resource it would seem going by how my salary responded.
Anyway, as poor old Janis would say “if you can’t be with the one you love, love the one you’re with”. You’ll be happier and your stress levels, blood pressure, social life and even maybe your payslip will reward you for it.
If it's something that's more immediate usually nature will take its course, but if it doesn't usually a quiet word in a tester's ear can elicit the necessary dialogue.
With regards to other people being "lazy" and "not fulfilling their role" I prefer to take a position of unconditional positive regard and presume that everybody is busy ... my cardinal rule when making big changes is "cause as little extra work for other people as possible".
Keeping people busy is management's responsibility, and if I'm totally going to pull the rug from under something I'll get them on board. If they tell me to leave it alone I leave it alone but I've told them what the issue is and its their problem now, to weigh up and act upon as they see fit.
Clearly there are some parallels with this story here...to be "popular", he should have gone along with whatever they were doing and slowly try to change things. Not saying that's right or wrong, but hey, that's apparently how you get popular.
One may be all of those things, but without giving the group an opportunity to discover that for themselves, they aren't going to listen to your suggestions. Or one may start by going along with the group, but be abrasive and obnoxious, and no matter how much time they spent with the group, they won't be popular.
Over the years we've backed away from considering the value of things on their technical merits. I'm not saying we shouldn't be thinking of business value, but you have to admit that's far more subjective. I'm not always sure it's a good thing. I'm convinced that maximizing business value and ignoring technical value is one of the main reasons so much modern software is crap.
I remember reading about such a case in Emotional Intelligence by Daniel Goleman. So, curious what is this course?
Interesting parallels to newcomers to tech/geek culture in general too.
And yet... somehow, it all works, and at the end of the day, they ship their product on time and make a boatload of money. So my visceral reaction to this code is a very strange mixture of horror and respect.
My approach to trying to get this mess fixed is something along the lines of, "You're the boss, and it's your call, but if I were one of your investors I would be very concerned about the long-term maintainability of this system if, God forbid, something were to happen to you."
Does this approach work? Hard to say. No substantive changes have been made. But I haven't gotten fired either.
Investors do not make fortunes based off the opinions of junior programmers nor on their understanding of the nuances of codebases.
Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.
My advice to you is the age old adage, put yourself in anothers shoes, go and buy some stocks, etfs, mutual funds what have you and experience the other side of business, let your eyes really be opened before casting judgement on processes you have little understanding of.
It seems as if you're going out on a limb here and inferring an awful lot about someone from a single comment, and your inferences both appear to be incorrect to an amusing degree...
Investors can lose money on bad code bases. Technical due diligence is a real thing. And getting a third-party opinion on "if your CTO dies, does your business also die?" is EXACTLY the sort of thing that comes up in those conversations. E.g., https://dave.moskovitz.co.nz/2016/08/29/technical-due-dilige...
If a technical audit comes back with "the CTO is the only person who can maintain this code base", and if the code base itself is a major asset the buyer is interested in, that can kill or substantially modify the terms of a deal.
> Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.
(e: removed silly speculation)
> ...go and buy some stocks, etfs, mutual funds
This provides zero insight into what technical due diligence looks like or how that plays into the overall decision to purchase or invest in a company?
Many organizations fear the departure of institutional knowledge that goes hand in hand with retiring baby-boomers. Many investors/corporations also take out life insurance policies for key employees because they are so instrumental to the work process. A labyrinthine code-base without well-defined knowledge transfer processes spell capital disaster.
Tell that to the investors in Knight Capital.
The author doesn't pick his battles intelligently. His victories are at the expense of his team: instead of making his team members look good he makes them look bad.
You want to keep what works, change what doesn't work.
If your team doesn't do it, another team elsewhere will.
Then, people never stay in the same job forever. If you use your power/team to stay mediocre, you are just acting against your own self interest.
One way to change a team is firing/hiring, and I bet many readers' minds probably went there first. But firing and hiring are very expensive, especially in a time-constrained business, because time has a cost. And only a few people have the power to do that.
Another way to change a team is to alter or improve the people on the team. The value of influence--the ability to change the minds of people around you--is underrated by a lot of people, especially engineers who spend most of their time in a headspace where things are quantifiable, black and white.
A new person coming into a team that builds technology, who wants to change the technology, needs to focus first on changing the team via influence. This is a skill that anyone can learn, but it has to first be a skill they recognize and value.
The lowest person on the totem pole can't fire anyone, but they can certainly influence people. In fact, the ability to positively influence the people around you is a key skill for anyone who wants to grow into a leader in their profession.
It is fine to spend time discussing and building consensus. And it is fine if your idea doesn't prevail. But the most important thing is how an idea prevails in a conversation.
If an idea prevails for reasons other than it being the most reasonable idea, like someone pulling rank, or having a higher speech rate, or louder voice, or just being more aesthetically pleasing, you've got a pretty flawed process and this frustrates objective people.
When a person consistently requires a lot of hours of "influencing", usually because their motivations are not aligned with the best interest of the company, you start looking for alternatives. e.g: having someone else to do it, deprioritizing, doing the job yourself, escalating.
When you have a team full of those people, best thing you can do is to make a better use of your time and work on another team or for another company.
I probably don't come off as a very nice person (my wife tells me I have a 'death glare' as my neutral face), until you get to know me. I once had a technical lead admit about a year after I had started a job that she had recommended against hiring me and was overruled by her boss. "You seemed like a jerk at the time, but now I realize you're just an introvert."
So, these days I try to paste on a fake smile when I interview, but to no avail. I suppose it might make me look a bit scary -> vacillating between "death glare" and "creepy smile."
Funny, I got (and turned down) a job offer earlier this week that was based solely on a couple of phone interviews. I turned it down because it was a large corporation and seemed very much like a butts-in-seats sort of place (hence, why would they care about culture fit and actually want to meet me in person?)
Few people can speak about things they love with a deadpan face or a frown on their faces. And a smile makes everyone look nicer and friendlier ;)
Especially an authentic smile!
(Note: Don't go on a half-hour story, though, a few minutes should be enough to lighten the mood.)
I see that in a lot of engineers. We are just not good at reading social situations.
Now that I'm a bit older than a young eager 20 or 30's something, I'm better at capping my stories before they get boring or repetitive. Leave them wanting more, or at least give them the talking hat back, they probably want it.
There are places I would fit well, and there are places even with my considerable talents I just don't. And you need to accept this.
If you even put it on your resume at all, it’s probably one of the easier ones to explain and helped by the fact that your old company re-hired you. “Would you hire this person again if given the chance” is a common reference check question.
However: Saying things like "I don't believe you," especially in a public setting, is a great way to come off as a jerk. Once you've decided to call someone a liar, the chance of them getting defensive (and thus poisoning your relationship) increases significantly. You've cornered someone instead of giving them an escape route.
Seems like it was a horrible fit on both sides: The author needs a significantly more accountable company, and the company needs someone with a much more delicate touch.
There is clearly too much conformism and flawed communication flow in this organization, which is a failure of leadership, and not of somebody who is "actually doing what [he] was paid to do."
The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."
If there is too much conformism, necessary conflict will be avoided and could not be utilized in a healthy way, leading to too much consensus resulting in "one-year old pull requests without review."
In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.
If a competent but "less socially aware" guy moves "too fast," why the team prefers to effectively mob this guy out of the organization, instead of just telling him to slow down?
No such context for constructive feedback, maybe?
This organization is just shooting itself from the foot.
Organizations that need to move fast cannot afford such conformism and dysfunctional communication.
That's unfair. Most people who are advocating for deference when first joining a team.
And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". Therefore, sitting back and learning the social and technical history that led to the current system is actually the correct place to be in the exploration-exploitation axis during the probationary period.
Both for social reasons, as well as for technical reasons.
That's very different from "put up with office politics". The point is not that you should be likable during the probationary period. The point is that people who go way the hell too far to the "exploitation" side of the axis so quickly are demonstrating poor engineering judgment.
Characterizing that poor judgment as "well I guess I'm just not PC enough" is just icing on the cake.
> The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."
According to this account.
I submit that it's not even obvious that the engineer in this story was even making the correct engineering decision. Engineers are not scientists:
> In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.
I think the core problem in this story was wasting a bunch of the company's time arguing over a heuristic that's "good enough" in practice. Both solutions would have been "good enough"; the engineer put his ego above producing value for the company.
> Organizations that need to move fast cannot afford such conformism and dysfunctional communication.
Organizations that need to move fast cannot afford engineers spending time to prove they were correct when going with the established heuristic would've produced a good enough result with far less engineering time involved.
If the story included a thorough cost/benefit analysis showing that the change saved the company $N0,000 with N > (cost of engineering time) then you might have a more cogent argument.
They're mostly not unkown unknowns. They're mostly arcane knowledge of some sort or the other.
And what prevents good communication of this knowledge besides either lack of competence or politics?
Someone didn't know or didn't care to do better and nobody held them accountantable for it.
In particular, the strange horrible code might be there for a great reason. But there is not a good reason for nobody to take five minutes to write a comment about why. And there is no reason to not ask for that comment when the change is reviewed.
B: Liked by the team
D: Neither correct nor liked
Managers are often okay with incorrect employees because they can be trained easily. (Whether or not management actually trains them, that's another story - but managers like to believe that they could.)
Managers are less okay with employees that everyone actively dislikes because it's way harder to train someone on how to get along with people.
It's kind of like in a marriage. The man keeps on doing something wrong (forgetting to pay the electricity bill, perhaps) and his wife keeps on pointing it out — and, rather than pay the bill on time, he instead gets angry that she's nagging!
Persuading people gently, leading them slowly but surely to realising for themselves that they've been terribly wrong, is extremely difficult and requires a high degree of social skills. Sometimes, it's simply not possible: sometimes a team-mate (or worse, team lead) has so much invested in an incorrect decision that he will never change his mind; the one's only choices are to live with the malfunction or leave the team.
I've worked with plenty of people whom I don't particularly like at a personal level, and would not have a beer with given a choice, yet were able to connect with at a professional level.
Honestly, this blog post had a "nails on chalkboard" sound, although it was written by the protagonist from his POV. My guess is that his co-workers would have said that he was a bit of an asshole, and made it clear that he was the "smartest guy" in the room. You can only pull off that bullshit if you are part of the tribe; when you're an outsider, that behavior lights up the organizations' immune response.
This, this, one thousand times this!
When I first started with my current job, I had lots of free time, a technical background, and a desire to carve a place for myself. So in the first week I went through the whole website and invoiced where I felt there were some easily fixable UI/UX problems that could make things feel better and possibly get us more clients. Sent that list up the chain of command. Nobody cared.
Fast forward a year: I've learned the culture, how to work with the people involved, and I'm being shifted to a more hands on role with the product decision making. I've learned how to work in the system, so now I'm able to expand my sphere of influence.
Where as many more of us percieve skills / knowledge as trainable.
You took the lead on your first week???
Based on your explanation, your co-workers were morons, but you made one of the most outrageous socially-wrecking mistakes that one may do: you showed an unwanted truth to people you were not even acquainted yet. After that, the cleavage is too deep to even try and feel it. I think letting you go was the right decision, the environment was already toxic and it would have taken years before it returning liveable, if ever!
When you join a new group of people, first of all try and adapt yourself to your new environment, and only later try and adapt the environment to you. Otherwise, conflict is inescapable.
This is an important point. This guy may in fact be annoying to work with (I don't want to pass judgement, but I started to suspect that while reading his post).
I can't even count how many times I ask myself "but they hired me on the premise that I'm an expert in this, so why are they not allowing me to work and make changes to improve things for them?"
For an example from a totally different direction, consider something like "Kitchen Nightmares". People with a failing restaurant, who know it's failing and have gone out and solicited the help of someone who's considered good at both cooking and turning around restaurants.
And at least 50% of those people still will resist many of the changes they're asked to make even though they acknowledge that they're failing. They don't really want to change, they want him to make them successful without changing.
That said, I'd suggest these issues are much more common in industries where measuring results is hard and where results aren't an automatic result of work put in.
"This thing will improve production on the assembly line". Great, try it on a line and see if output improves. Hard to argue with the results if it does, even if it's just 5%.
"This thing will make better code/software". We can argue about this for hours, we can trial it, and unless it's a massive leap forward it's unlikely you'll get such a clear-cut result that a person biased against it/against change will be swayed.
Being technically competent isn't the only factor in job retention. I feel like this is an especially difficult fact to accept for some of our tribe.
It's kind of a motto where I work. Others are surely familiar with it too. I'd also add that baseline levels of sanity, competence, etc. are all part of intent for the purposes of this admonition. It's a good rule, and the OP demonstrates exactly how things can go sideways when it's not followed.
Maybe others didn't recognize the author's good intent, but he clearly didn't recognize theirs either. As far as I can tell, he doesn't think they ever did a single thing right until he came along, which is a huge red flag. I doubt he felt that way when he accepted the job (why would anyone?) so it reeks of post-hoc rationalization. Remember, we're only hearing one side of the story. Chances are, even if he was right on the major points, he has elided how his first ten "you just need to" proposals had to be amended in a collaborative process for which he denies anyone else any credit. Counting the hits, ignoring the misses. If he had assumed instead that other people weren't idiots, that they had reasons for what they'd done and would be amenable to reason, there might have been a better outcome.
P.S. Yes, I know sometimes people really do lack good intent. Some people really are mean, stupid, crazy, etc. Believe me, I've worked with a few and I've called them out on it ... but only once there was incontrovertible evidence of those things. It doesn't change the fact that it's better to start by assuming good intent.
My advice to anyone in a similar situation: work on the classes of behavior that are actually problematic, namely blaming, defensiveness, contempt, and stonewalling. Then you can have a healthy argument about ideas.
If a team has problems listening to actual, clear evidence that what you did was correct, they are perhaps at fault here. Of course, if you show contempt, then the right thing for a healthy team to do would be to:
1) Address the contempt head-on, and then
2) Examine the data dispassionately.
It seems this team failed at both.
Probably a good thing to get fired from such a place, though it hurts to not be given an opportunity to move on on your own terms! This particular org appeared to be a pretty bad place to work anyway.
I didn't draw that conclusion at all. It didn't sound like he was advocating healthy discussion. He came off to me as being brand new to a team and insisting on his way, while not being open to any explanations of why that either wasn't a priority or wasn't viable at the moment.
Walking into a team as a new member and immediately insisting on sweeping changes is never a good idea.
Do you just go along with it? What do you do? I personally try and avoid places like that like the plague because it will mean my technical skills will vanish with the wind the more time I spend working in such a code base.
Is there an industry where people like me get paid to keep people like the author from self-destructing in a near-perfect job environment?
It's good, but rare, to be irreplaceable.
It may just be the examples this author gave that made me think of this. An initial temporary team where everyone is clearly less skilled than you are? Dear lord, feed them the answers so that they get credit for fixing the security issue. Everyone will then sing the praises of working with such a team player.
Work closely and non-combatively with the tech-lead to get a full picture of their knowledge and level of defensiveness. Then stay out of the tech-lead's way while you slowly begin building up a robust testing system. Make sure each pull request is short and easy to read. Space them out so you don't make a pile of work for your colleagues.
Pretty soon you'll have a bunch of allies, probably including the tech-lead. Or if the tech-lead is still defensive, you'll have a big, fortified wall of unit tests between the two of you. They'll be forced to argue with failed tests instead of with you directly, which is one of the few (and perhaps one of the only) benefits of technological progress.
The better you are (or think you are) the more difficult this is. When I start at a new job I never criticize the code because you don't yet know who wrote it. If teammates grumble about the code base I pick parts to praise. This is counter-intuitive because foreign code and practices are almost never appealing. It is far more important to judge the team culture and fit in than demonstrate your technical ability immediately.
Unfortunately the author does not seem to have learned his lesson as most of the article is about what he did 'right'.
When I interview candidates I attempt to engage them in technical argument where I purposely make some questionable statements. How do they attempt to correct you? Do they leave the door open for their opinion to be incorrect. You can learn a lot about what someone will be like to work with just using this simple technique.
This is a very good idea! Thank you very much.
Working too fast in these situations can and will cause cohesion problems. In this situation, if you have a fix for something that will save weeks of work, don't take a sniff test of the general atmosphere, and just charge forward guns blazing, you will make yourself an organizational pariah.
The easiest way to tell if you're in this situation is to get in a closed door meeting with your middle manager and explain the difference between what people believe about the situation and the actual situation. Maybe even do the work first so you have some solid proof that you're right.
Your manager will know the political atmosphere and how to navigate it better than you will. In most cases, he'll give you political cover to implement your fix and because it's coming from on high, you won't get resented for it.
Of course, if this starts happening a lot, then you need to have more discussions with that manager about a promotion.
There is, however, a certain obligation to try to get along, to help new hires to become part of the group, to overcome all the biases we all have etc.
I’ve also not seen too great a tendency to streamline personalities for the sake of “getting along”. Indeed the most fun and productive groups were rather diverse sets of characters, including the stereotypical “asshole genius”. Somehow, they managed to keep insulting peoples’ work yet showing enough self-awareness to make their subjects not feel personally hurt.
> This accusation lead to another confrontation where I became aggressive (the guy attacked me personally), which probably was the last drop for them.
This leaves a lot of room for interpretation. If he got physically agressive he would be fired on the spot pretty much anywhere.
But I have found the share amount of employees, which just bloat confidence in anything they say, even if it is the wrongest thing in the entire Universe.
Always prefer to lower the bar around the quality of code, translating into more problems with future requirements, readability and so on. The reason? Self-preference to bad habits, but also the "no time" excuse, which in some cases might be the appropriate choice, but in others simply translates onto an obvious lack of ambition, but also a mind-blowing lack of respect for the programming art.
And I say this knowing that I am nowhere near the level which I want to be and very far away to actually produce code that I can consider to have met the standards of anyone with level of expertise in the same subject.
The author clearly seems to know computers, but in general from reading his post, he is a bad engineer. He collaborates poorly, he offers solutions without context, and does dangerous things without even realizing it. (eg: the use of BATCH without consideration for the negatives of such)
One thing to realize is you are holding an absolutist view of programming as an immutable art form. Programming computers is an engineering discipline. It exists to serve an external purpose - help people, make money, solve problems in the real world. Like every engineering discipline, it involves a trade off. Marking off your coworkers as "obvious lack of ambition" and "lack of respect" in their efforts based on your own judgement of their coding skill is intensely disrespectful. That's the kind of attitude that is inherently pre-judgemental and is what can get you fired, not hired or just edged out.
Having worked with truly intelligent individuals, one thing I have noticed is their endless humility and lack of ego. They are kind, think well of others and endlessly question their own intelligence. The author falls short on every metric.