Did anyone really read this till the end? If your conclusion is that the best programming advice the author ever got was to “stay the hell out of other people’s code” please try to read it again... that was exactly the opposite of what he meant. Best advice I ever got: always read things ten times before responding.
> “Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since. But those words were valuable nevertheless, and I've gone back to them time and again.
Every time some annoying new-hire comes to me with a dumb idea that is obviously not going to work, Stay the Hell out of other people's code plays back in my head and I listen harder.
Every time some other engineer has an opinion about my code, I remember what I thought of the idea that you should mind your own technical business and I try to disengage my ego.”
True, but with so many people with reading problems, it would behoove any author to state his thesis simply and plainly in the first paragraph, in straight text, with no sarcasm, allegory or metaphor. Otherwise you run the danger of bringing upon us another Waterfall^1 situation. When giving advice that could be read and acted upon by managers, please try to make your text's meaning resilient against shortening. That is, it should be possible to cut out any amount from the end of the text and end up with either the intended meaning or no meaning.
^1 - The original Waterfall paper describes Waterfall as what NOT to do, but this becomes apparent about halfway through and then goes to suggest something very close to Agile. Unfortunately, if you just read the start of the paper, maybe if you're a pressed for time manager, all you're left with is an impression of how great Waterfall is.
I know, and it's not even like it's a long article. They must have got to that sentence and then just rage quit or something.
It amuses me, but I won't say I've never done it myself, particularly when I'm already tired and irritable, and I'm reading a piece by an author who's taken a provocative stance without quickly getting to the point. Tough to make that accusation stick here though.
There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life.
In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question.
When my electrician has a power supply over here and needs power delivered over there, we all know he's going to use wires, and he knows the right gauge to use. He's got a book somewhere with the answer, and there's a regulation somewhere that says what he's required to use. But I just trust him to use the right cable, because that's his specialty, and I've never seen him make something that was an order-of-magnitude worse than was required, or that I could do on my own.
Respecting boundaries is a lot easier when you can trust that other people are generally competent. This will continue to be a problem for the next 100 years until we figure out the right way to make good software.
That's an interesting perspective. I think you're right that we don't have "correct" and standard answers because we don't assume total competency, but I think we don't assume total competency because software development (both the requirements and the practices) change fairly rapidly. I wouldn't be surprised if in 100 years, we're still trying to figure out standards, if the pace keeps up.
>>There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency..
I don't think anyone argues with that. It's just that sometimes some of the biggest impostors hide behind "boundaries".
>>This will continue to be a problem for the next 100 years until we figure out the right way to make good software.
A lot of people figured it out already.. but those are a minority and the field is fueled continually with poorly instructed people. The Business can't distinguish quickly between these two categories and often it does not even bother (good interviewing is hard or expensive) because (in Europe) it's not the software efficiency or other quality making the profit.
Individual "masters craftsmen" have always figured out things like this way before they have become common practice. But I think original poster was meaning "we" as a profession stabilizing on standard good practices that everyone knows and uses, not just a few masters.
Software is not the first industry to deal with systems complexity or large teams management but (in my part of the world at least) it's the first to expect engineering-like results from non-engineering workers and managers. There are developers who have noticed the similarities between creating/assembling/testing components & modules in other industries and software and borrowed practices before software had a name for them. It's just that these people are dispersed in a sea of devs tuned to Microsoft Framework Factory or busy building castles on Javascript Frameworks Sands.
" There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question."
When foo and bar both solve the job and equally fast, then yes. But in the example of the article the other version was much faster. So faster (assuming no bugs got introduced) means clearly the correct answer here.
That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that no bugs got introduced, nor that execution speed is the only metric that matters.
Perhaps the existing socket-based solution simply used a bad timeout, and instead of a weekend of work to completely change the architecture of the system, it could have been fixed by changing one number in a configuration file. That would have been much lower risk, and not affected any other functionality, test suites, debugging practices, support procedures, etc.
Software is still a young field that celebrates youth, and single combat warriors, like "Mel". It reminds me of Tom Wolfe's "The Right Stuff", about the U.S. space program back in the 1950's. One person could and did go do crazy heroic things that helped a single flight succeed. Eventually, space flight grew up, and NASA today barely even mentions the names of their contributors and collaborators. They'd never put up with cowboys like that any more. That's not how you achieve successful, repeatable results in complex systems.
I don't think the single combat warrior is the right analogy for the article. Instead, to me it felt more like a "The Emperor's New Clothes" kind of situation, in which a naive [1] youngster inadvertently exposed the dysfunction of the organisation. Judging by the author's description, nothing that could have solved the performance problem – not even a simple config parameter – would have gone over well in the war between the two factions.
[1] "Naive" as in unaware of the ongoing office politics.
Killing sacred cows in software dev is a crucial part of the overall process if you’re going to keep a product alive long term.
Learning HOW to kill a sacred cow without pissing everybody off around you is a crucial part of learning to become a senior leader.
Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”.
> Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”.
You're not wrong, but equally I'd argue that if you need a huge amount of groundwork to implement change, you're probably in the wrong organization.
Good organizations value good ideas, irrespective of who thought of them.
I'm not disputing that and in general I think that holds as a good litmus test. If you're always having to push crazy hard and nobody listens, one party is failing here (its either you or the company, situation dependent).
That said, my experience tells me there's a lot more to it in some cases, org dependent.
For example - all teams (even great ones) go through phases where they can tolerate more change than at other times. Why that's true is itself a huge list of factors ranging from what the org is doing as a whole, all the way down to the team itself and how they're currently working.
It also matters how the idea is spread among a group. If the idea has legs, theres going to be a lot of broken telephone if you haven't correctly setup the context with thought leaders (which may be different people to the managers, who also need to know what's coming). This gets more challenging as the number of people involved gets larger.
> Good organizations value good ideas, irrespective of who thought of them.
Ideas with only upside and no downsides may be trivially executed. The problems come with ideas where costs are certain and up-front, while benefits are medium-to-long term, and the transition may carry risks of its own. Big changes and ideas usually are disruptive and the best organizations may still struggle to pull them off.
In my experience even in good organizations people may have different assessment of what's a good idea precisely for these reasons, and getting people aligned behind such changes is what leadership is all about, and does need patient groundwork.
I think these days just find out what your direct manager and one aboves favorite metric is and pitch it as upping that. Faster performance improves user experience almost directly.
I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit.
When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...”
they told me to give all the related code, documents and remove everything from my computer. After that incident I never got promoted, my annual bonus was always 50% of everyone’s. No one in the team wanted to talk to me, I was excluded from any design meetings. Eventually my whole team got promoted to principal engineers and all new comers were one level above me. That was the worst 4 years in my life ( I had to work for them because of the work visa)
Answering all questions. One thing i left off is the reason why I was in hot water:
Everyone in our organization is really “rank-orientated”, I challenge their intellect and their baby they were proud of - it was foundation for our organization to even exist in company. Even though it was outdated, poorly designed system, that produced high percent of outages and heavy on maintenance. But it was not my place or position to do that.
It's also possible your solution wasn't as elegant, maintainable, or as performant in all cases as you thought.
If you're going to approach upper management with such a hostile attitude, you need to run it by some peers first to have them poke holes in the idea and get onboard.
Why I called your approach hostile: you phrased it as "challenging their intellect". That's not how good engineers pitch changes.
Did you suggest "I can make it better, faster, more stable...?" or did you go ahead and make the change and say "see?" Were you in a position where you should even have been thinking about this system?
I wonder what steps in this story you're leaving out?
Of course I did not just go and implement the change in production. I had put together PoC and documentation how and why it’s better, more error resilient and effective. The reason for just reaction was politics... I put my nose in other people business.
I don't understand this, or the linked article. Can someone explain to me what possible reason there can be for responding with disciplinary action when someone proposes an improvement?
I think this quote sums it up best: "I've realized that there were probably a dozen programmers on that ancient project who knew why the system was so slow and how to fix it. They knew, but they kept it to themselves because in that organization, there were some things that were more important than making the system better." The mistake was in assuming that code quality and performance always trumps other considerations. The title is misleading in this respect: it's not really programming advice. Even the phrase repeated in the article, stay the hell out of other people's code, is more about navigating the potential unknowns of a situation, and being in touch with what's happening around the office more generally.
An easy reason that often gets left out of these stories is that someone spent weeks on a rewrite without authorization rather than working on burning priorities.
That's a real problem, and quite common. I think it's important, when confronting or correcting someone doing that (whether they're your employee, colleague, superior, team lead, etc.) to emphasize that they're not being punished or thought poorly of because of their ingenuity or initiative, but because they're wasting time and need to stick to the plan. Otherwise, initially headstrong but very capable people are often ground down before they have a chance to get used to the roadmapping/planning/etc. process at a company. This is especially true with new engineers.
I have no idea if the GP post you're replying to is someone rationalizing being in that position as being "disciplined for touching the wrong code", or whether something actually screwy was going on. I just wanted to mention that distinction because it was important to me when I started out (if people had come down on me for having ideas, instead of for wasting time, I'd be in a much less useful, happy, and capable place today).
I look at documents and remove everything from my computer, and my guess is that op worked on it on his own time on his own machine. He was still working 4 years in that company, so he was not removed from project. Feels like action was uh, he got documents out of company.
Don't get any data out of company, I would never promote someone who got any documents out of company laptop to his own.
When they've gone on an unauthorised excursion through some code that has say, safety critical or legal, concerns some off the top of my head examples.
Hey guy's I've rewritten:
- The dosage control code for radiotherapy device so we can remove that expensive mechanical interlock!
- The data access layer of our patient records system!
- How we calculate x in out guidance software we can go to a cheaper CPU now!
especially if said code was rattling in the building around somewhere it might get into the code base.
In those cases, why not respond by explaining the risks or other considerations that might not be apparent from the code?
Frankly if there is real risk that the code is pushed to production by someone who shouldn't be touching it is a failure to properly safeguard critical assets.
Retaliating because someone tried to make something better is abusive and dysfunctional.
> When they've gone on an unauthorised excursion through some code that has say, safety critical or legal, concerns
> especially if said code was rattling in the building around somewhere it might get into the code base.
Reading code should never require "authorization". There might be some edge cases related to logistical technicalities (e.g. there's a security clearance/IP/trade secret/plain-text password concern). But there is no reason that the criticality or risk from changes to code should prevent people from reading it.
Writing or rewriting code should never require authorization; getting it released should.
That's not some 'everyone should do whatever they want, damn the managers' statement: do your job and try meet your goals; if you go off the reservation and waste time, don't be surprised if you get slapped. If you take your code to your boss/team and they say "that's too critical to touch right now/at your experience level", "I don't have time in my day to review your side-of-desk rewrite, shelve it", or "that's incredibly misguided and too stupid to even try to improve", that's on you to work through.
But the act of [re]writing code alone should never be forbidden.
If one of your job's responsibilities is "don't rewrite this code, even as a scratchpad or personal what-if,", that is fucked.
If one of your job's responsibilities is "don't read code that is out of your lane, and don't try to understand the haunted forests"[1], that is fucked.
Your responsibilities might not be explicitly to do those things. But if your responsibilities include the negatives ("never touch this, even if you don't check it in"), something is very wrong.
If code "rattling around the building" might somehow "get into the codebase", that is fucked: you have a horrible problem with your code review process, your release process, your developer prod-access/permissioning system, or your colleagues' willingness to accept as gospel things they find lying around. Or all of the above.
To be blunt, that comment seemed harmfully closed-minded, paranoid without reason, and lacking in understanding of how engineers grow and learn: by reading and writing code, even if nothing release-able comes out of it immediately.
Similar thing has happened to me. I joined a security team in a Big Bank. During the first month of my work I discovered a terrible and obvious security hole, which was there for years. My manager took me aside and explained that they can't fix it, or even start doing anything about it, because the whole team will look incompetent. I was told not do anything and reassigned to the completely different tasks far from the team. After another month, I left.
The fact that he was a foreigner provides a hint. It seems there's a general fear in the US of foreign workers taking the jobs of citizens. I wonder, is it not possible to switch employers when you have a work visa?
there's a general fear in the US of foreign workers taking the jobs of citizens
Comments from our idiot president and his ilk aside, there is not. I'm willing to entertain discussions to the contrary, but this is far from my experience either here in the Midwest, or on the East Coast where I previously worked.
I worked for the US counter part of an Indian company in Illinois for a couple of years. We used to have town hall meetings every quarter. On 2 such meetings, I heard two separate American employees questioning the speaker about outsourcing more. He would be talking about how they are planning to spread out a project with 20% in US, 50% in India, remaining in Europe and some other place. In both the occasions, they asked questions that meant why only 20% in US or something similar. He always replied that's what the customer is willing to pay, that the customer has so and so budget, and this is how we are meeting it.
Or maybe more realistic and less paranoid: the code he wrote was more performant but significantly less maintainable. Look at it from a director's perspective. Technical debt from an H1b. Is he trying to maintain job security by being the only one who understands how a critical module works?
You seem to have jumped to a conclusion rather quickly.
Even assuming for a second that the hysteria was because the new function that GP wrote is complex, wouldn't the reaction to that would've been "Can you write it more clearly?" instead of the hysteria and pariah ceremony?
In this scenario the lack of performance was significant, so I would say it was necessary. If performance was adequate, different story.
For example. We have a redux based content editor that is quite slow. It is however more than performant enough for the use case. I would love it if someone refactored it though...
You don't know how significant the performance difference was. You're just believing the commenter who thought it was without hearing from the company who obviously didn't think it was a priority.
Personal attacks will get you banned here, regardless of what details someone else left out. Please review https://news.ycombinator.com/newsguidelines.html and post civilly and substantively, or not at all.
This would be a personal attack if it was wrong to be stupid... But it's not. Everyone acts this way sometimes.
I don't even suggest they are stupid all the time, just acted so in that moment, which again is completely fine but responsibility should be shifted.
I'm sorry the use of that word is too much for you to handle, and I probably should have used another method to call out someone's mistakes. I'm also slightly disheartened that hackernews thinks the default use of stupid has to be cynical.
That's my mistake and I will adjust to the fragile culture here.
It wasn't just that one word. Telling someone they "want to play the victim" is also a personal swipe, as is "this is 100% your fault" and even "you're clearly leaving out some important detail". In fact, your comment consisted of nothing but swipes!
One argument in favor of such an interpretation is that anytime somebody posts such an anecdote, and in various contexts that happens not infrequently, there is one giant thing all those story tellers forget: That everybody else only sees their side of the story, and that posting something that looks so one-sided "everybody was being stupid but me" is better not posted at all because of how unbelievable it looks, even if it indeed is true. If they had any good level of people-understanding they would in my humble opinion be much wiser to not tell the story here, or at least not make it look so one-sided, or add some disclaimers showing some self-awareness that shows they at least considered that they themselves are a key part of the problem. It reminds me of that joke of the guy who is driving a car on the autobahn and hears a warning on traffic radio about a wrong-way driver right where he is driving. "Only one?" he says to himself, "Hundreds!"
Your comment and many of the siblings just read to me as random victim blaming. "Oh, you were mistreated at work? I bet you are lying and incompetent and were actually entirely at fault."
the parent is relaying their personal experience, why would they have to add disclaimers about one-sidedness? A forum like this is literally just people telling "their side" on various topics.
I've been mistreated at work and find the parent comment very believable. If you haven't been, then you are either young or lucky. Good for you but please don't just discount other people's experiences.
The author, Russ Olsen, has written a book, "Eloquent Ruby".
It's probably the best programming book I've ever read. It teaches high-level concepts, hard technical stuff about how Ruby really works, and does so in a conversational voice.
And in all of those points it succeeds spectacularly. He never sounds arrogant, he never feels colloquial to the point of being imprecise. Just… pleasant.
I have cooled down on Ruby and don't have much use for the book nowadays, but if you use Ruby, get this book in preference to all others. Including the "essential" Dave Thomas book.
I've had a copy of Eloquent Ruby on my bookshelf for years, just sitting there collecting dust. I picked it up yesterday after reading this comment and, while I've only made it through the first four chapters, I have to echo the sentiment. Once I finish it, I'm going to give it to a junior on my team. I think they're at a point in their journey where the messages in this book will really help them.
I second this. I've mentioned "Eloquent Ruby" several times to Rubyists as one of the best books I've read on Ruby. Russ Olsen makes difficult concepts digestible.
My only guess as to why it's relatively unknown in the Ruby world is that it's quite old. Perhaps a new edition could have fixed that?
I had a similar experience and similar results. Someone wrote code to perform 1000 queries to pull back 1000 rows in a specific order rather than issue one query and let the Java collection order the results. Amazingly, another person wrote more logic to add a switch to skip this step because it literally took 10 minutes for the app to start when connected over VPN. The fix was trivial and startup time went from 10 minutes to 300 milliseconds. Being the new guy coupled with the fact they had actually lived with this for years, I was immediately hated.
Oh man. I am so glad that I had the opportunity to work at an organisation that actually celebrated a few such improvements i made.
There was a data ingestion job which inserted 4 million keys into Redis. It was awfully slow. I sped it up a lot using the Redis protocol format and redis-cli --pipe. They praised me for that.
There was a dashboard which queried data from a MongoDB collection and calculated some counts. I changed the design so that the service itself would update the counts so as to avoid costly queries.
I brought down build and deploy times for a service by removing unused gradle dependencies, structuring the build to allow using parallel builds and removing unnecessary configuration generation using templates and the entire team was glad that I solved a major pain for them.
Sorry you had a bad experience but I think this is what we mean when we say company culture.
Oh man. I am so glad that I had the opportunity to work at an organisation that actually celebrated a few such improvements i made.
There was a data ingestion job which inserted 4 million keys into Redis. It was awfully slow. I sped it up a lot using the Redis protocol format and redis-cli --pipe. They praised me for that.
There was a dashboard which queried data from a MongoDB collection and calculated some counts. I changed the design so that the service itself would update the counts so as to avoid costly queries.
I brought down build and deploy times for a service by removing unused gradle dependencies, structuring the build to allow using parallel builds and removing unnecessary configuration generation using templates and the entire team was glad that I solved a major pain for them.
Sorry you had a bad experience but I think this is what we mean when we say company culture.
It's not about the tech, it's about the politics. If everybody agrees Redis is the way to go, sure, go ahead and optimize it. But what if there's a VP who's been arguing that using Redis is a mistake and you should be switching to MongoDB?
If you criticize a seniors ideas, and they interpret it as you coming after them, you better destroy their reputation, or they'll destroy you. It's hard to destroy someones reputation within an organization, and most people get defensive when newcomers (especially juniors) come in with suggestions, so it's typically not worth kicking the nest.
> most people get defensive when newcomers (especially juniors) come in with suggestions
Reminds me of that quote "science progresses one funeral at a one".
I had a good boss at a previous company. Shortly after I was hired, he scheduled a meeting with the rest of the team and said, "We want to get your opinion on this thing X we've been working on for over a year. Since you're new, you may have some fresh perspectives about what can be done." I generally think that's the right approach.
Judging by the number of systems in different fields that have been overhauled by outsiders to the field, I imagine real innovation has less to de what thinking of new ideas and more to do with navigating the minefield of human psychology.
In college 10 years+ ago, one of my roommates had a laptop with 500MB ram and took a 500MB ram chip from anther room mate's laptop to speed up a game he was playing.
He did this without the knowledge or permission of the laptop's owner who was sleeping and forgot to put it back.
Morning came, owner woke up to a laggy system. Discovered the cause and went straight to the culprit. Instead of an apology, he got insulted and reported to school authorities.
Culprit panicked and threw his own ram into another room mate's locker - not knowing that rams have brand names and serial numbers. The owner refused the found chip and after a search, found it in the culprit's laptop.
Case over right? Wrong!
We all got called up to an office and asked, "Who do you think took it?"
I naively answered with all the logical evidence. The "judge" accused me of slander. And warned me not to talk about it any longer or face disciplinary measures.
I later discovered that the culprit's father visited the official and our meeting's true purpose was a coverup.
In other words, be wary of higher-ups who ask for critique, advise, improvements, ideas...
I’ve always been wary of one-to-ones with the manager for the same reason. Is it ever good to talk about problems with a manager, especially regarding other people? It’s like the prisoner’s dilemma. I still don’t know what’s best for me to talk about in this setting.
If you have a good manager, yes, it can be. A good one will often have years more experience at navigating tricky social and political situations than you do and will be able to help you work through any difficulties you're having with coworkers.
Good managers are far rarer than good programmers, though.
A decent litmus test for whether your manager can help with these kinds of problems is whether they've been on lots of productive projects and whether everyone likes them.
If both things are true, they likely are quite good at navigating interpersonal conflicts and arriving at win-win outcomes. It's nigh-impossible to achieve both those outcomes in a large organization otherwise.
I’ve given up on the idea of good and bad people. I myself am good or bad depending on how it suits me. How could I do anything else?
From my experience a manager will choose the option he thinks is most beneficial to his continued employment in the company. This includes maximising team support/influence over for instance making a change in a product with measurable benefit to the company, a change which even he himself might agree is a good idea. Who could blame him? Any manager who didn’t act in this way would surely be naive and idealistic.
Assuming this is true for managers, what benefit could possibly be had from complaining about other colleagues. It could only serve to reduce his trust in me, and increase his fear that I would do the same to him.
It is very difficult to balance things like team support, ensuring that I have interesting work to do and also ensuring continued employment. I have been too naive and idealistic, and now I am looking for a change of strategy.
It’s all well and good to be aware of these realities, but much more difficult to put the conclusions into practice. Sometimes I think you’re just born with it.
A further reply, beyond my simplistic defense of my use of the term "good manager":
It sounds like your "naive and idealistic" manager overlaps with my "good manager".
I will argue that a manager's principle responsibility is actually to be a maintainer of relationships. Her responsibility is to maintain her relationship with each of her direct reports first and foremost, next to help them maintain their relationships with each other, and finally to help them maintain relationships with the other employees/teams in the company as necessary.
Managers do have some logistical tasks they have to take care of, but mostly they "manage" humans, and that is fundamentally about keeping the relationships healthy and functional.
It sounds from your description like you've never had a good manager, and I'm sorry for that. The good ones definitely are idealistic, but they're not naive.
They are, as I mentioned earlier, in much shorter supply than good programmers. I've worked with far more decent programmers than I have decent managers (though since teams have N programmers to 1 manager on average, that may just be sampling bias).
I should also note that when I'm having trouble with a coworker, my default is a one-on-one attempt to resolve the issue(s) directly. If that fails (or in the rare case where I think it's a bad plan), I don't go _complain_ to my manager as such - I ask for their help in mediating conflict and negotiations. Because a good one focuses on relationship maintenance, they're often better at handling those situations than I am, and at helping the different members of the conflict understand each other and resolve their disagreements amicably.
Again - good ones are rare. I'm sorry you haven't gotten to experience one, from the sound of it.
I never said the manager was a good or bad person. We all do lots of good and bad things, and the labels overall are pointless to apply to people.
I did say "good manager" - for a particular role or job, I find "good X" an acceptable shorthand for "understands the core responsibilities of X well and reliably executes them well."
Test people in different ways to see if they can be trusted. Share inconsequential secrets and see who else hears it. Once had a boss who'd let cash drop while walking to see what you'd do.
If you can't trust em, update your CV and get busy getting a new job you become desperate.
I’m not sure things are so black and white. Although I would agree that trust is earned, I don’t think trust is the most important thing.
Rather than relying on trusting other people in the workplace, it would be better to develop a system where people both trust you and rely on you.
If I go to my manager and admit to him that I have problems, he will immediately suspect two things. One, that I don’t get on with people, and two, that I might rat him out one day.
I have not been able to apply these ideas in real life, as I have been much too idealistic. I’m looking for a new strategy.
As a manager, it's far better for you to come to me with a problem than it is for me to hear about your problem from somebody else. (And if the manager is any good, they'll know about the problem already.)
This a beautiful story, but the title is wrong. It wasn't "the best" advice, it was "the most important advice". Big difference. The advice itself is terrible, but getting the advice, particularly from the top boss, is incredibly valuable.
The way capitalism is supposed to work is you quit this job and open a shop which does the same thing as the existing company but doesn't artificially reduce speed, using that as a competitive advantage. The end result is that the first company is required to either adopt your strategy or fail, either solution leading the consumer to a better result.
I've seen it happen more often at a startup than at the giant company I now work for. There are some people who will act like that no matter the circumstances.
No, "proportional" just means the two things correspond in size, not that the sizes are equal. In other words there is a positive correlation between the values.
According to the Wikipedia page for proportionality[1], the values "can also be viewed as a two-variable linear equation with a y-intercept of 0". Direct (as opposed to inverse) proportionality is a type of positive correlation but they are not the same thing. Because we are dealing with probability percentage as a proportion of the company's size either the size is greater than zero and the probability is 100% or both values are zero.
So, I think you're confusing 'probability' with 'cardinality of the set of successful outcomes' (let's call that k). If k is proportional to the size of the company (n, say), then you are absolutely right that k/n (i.e. the probability) will not change as n changes. But the statement actually says that the _probability_ is proportional to n, not k. So no, the probability is not constant.
The idea of the probability being directly proportional to n is not technically correct for other reasons (with large enough n, this would allow for probabilities larger than 1), but not for the reasons you're mentioning here.
Perhaps more importantly, the meaning of the comment is independent from this pedantry and should be interpreted less literally so we can focus on its actual meaning.
I don't think "100%" and "probability" can exist in the same sentence (speaking in binary but also saying 0.999)
I think the parent was inferring that there was a chance progress could be reversed at his/her past companies because of the office politics/territory/decorum mentioned in the original article.
Raw efficiency averted by someone's need for the spotlight.
Building something that works in a short period of time when a team has failed to do that over several quarters demonstrates little more than the fact that your organization has hired people less competent and productive than you.
Unless you want to work where you're the least competent person, this isn't necessarily bad.
Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people. It is simply cheaper after the company grows to a certain size.
Process is more repeatable and predictable when programmers are more or less interchangeable mercenary byte plumbers who care about their own career growth compared to when everyone is deeply passionate about quality and competent about technical excellence.
> Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people.
I can't imagine an aphorism I disagree more with. I constantly come across companies with similar-sized platforms where one has a development staff 10 times the size of the other (both in cost and size), all due to the complexity and quality of the code. In the long run, few things are more expensive than a mediocre programmer.
"In the long run, few things are more expensive than a mediocre programmer. "
Disagree very much. Mediocre programmers are very good for mediocre tasks, of which there are plenty of.
The problem is only, if mediocre programmers work on advanced tasks.
How do you stop mediocre programmers from working on advanced tasks, and is the overhead of doing so greater than the cost of hiring excellent programmers?
Mediocre devs simply can’t do advanced tasks. They’ll spend months with no results. I’ve seen this countless times, especially working with offshore teams. One project was hobbled by terrible database performance. The app simply couldn’t scale. I listened to weekly calls for a year while they floundered. Finally I researched their connection pool and told them setting to control “verify connection before each call” to “verify connection every n milliseconds”, and told them how to fix it. I made sure to do it on a call with their architects and leads and our senior managers. Yeah that was a bit of a dick move on my part but I didn’t care.
Problem is there is a class of mediocre programmers who do get results - it's just that they are productive building things that appear to work just long enough for them to be able to move on to the next task, but their work either doesn't scale or falls over in production.
"How do you stop mediocre programmers from working on advanced tasks"
Competent project lead/management
Assigning the right person for the right job. But yes, nobody ever said that is easy.
But in general: by definition there can be only some excellent programmers and lots of mediocre ones. So it simply would not work if every company only would hire excellence.
And it is also not neccesary nor useful, since there are so many boring, mediocre task around, meaning the excellent programmers can focus their time and energy on the complex, interesting problems.
You're absolutely right, but what he said is also true: the act of hiring by itself becomes fairly unscalable unless you're lucky and get a constant stream of good candidates (which again won't work in your favor if your company isn't primarily known for its engineering).
It does become more difficult (most people don't hire people who are better than they are). That's different from saying that mediocrity scales better than skill. Skillful programmers understand points of leverage and reduce maintenance costs over time.
Purposefully hiring mediocrity? Big companies do it, but not on purpose. Survivorship bias is in play here. Taking that approach is a form of managerial cargo culting.
I definitely know some big companies that hire mediocre people on purpose to make sure they stay back and don't leave in a few months. Needless to say those places suck to work.
> Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people.
This becomes less and less true as the size and complexity of the relevant software projects grows over time. If highly competent developers have anything going for them, it's their skill both in successfully coping with software complexity, and in preventing undue complexity/keeping it under check in the first place. See also The Mythical Man-Month, etc. etc.
Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments.
Bad advice if you want anything more out of your programming career.
Horrible advice if you want to make a difference by sharing your gifts with those who need them.
You don't get that many chances to do what OP did by jumping in and making dramatic improvements.
The only reason I have ever avoided staying the hell out of legacy code was when opening that can of worms was just the wrong thing to do for everyone.
Otherwise, I got the hell in there.
Sometimes I was thanked.
Sometimes I was reprimanded.
Sometimes I was fired.
Always I learned something, usually the best learning I ever had.
(And as for getting fired, I wouldn't have changed a thing. This is actually a good thing. Better to push the limits, find out who you're dealing with, and move on quickly rather than being miserable for years without ever understanding why.)
The Best Programming Advice I Ever Got? ... Always Do the Right Thing. (Even if it takes a lifetime to figure out what that is.)
Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsense and second because it avoids having people that are single points of failure (only one to work on this part of the code).
I would consider toxic a work environment where somebody would talk about "my code" after it's been merged.
Say that a bug occurs in the code that I wrote and I'm more familiar with than anyone else on my team. I'll gladly say "I wrote this, I'll fix it".
In a perfect world, we'd all understand every part of the project as well as the next coder. But in my world shipping features on time is often more important.
I do not consider my work environment toxic at all. Just an agile startup
I think you’re both in agreement. “My code” when it’s a bug is fine because you’re really showing humility and responsibility. I think it is the one exception to “our code” being used as the standard way to refer to code. When the code is great it should be “our code” and by proxy the team’s success. Not one person’s. And when there’s a bug that’s not your own it should be “our bug”. You don’t want to throw anyone under the bus because we all make mistakes. (That’s not to say all bugs should be ignored. Your team should investigate why their code failed and how they collectively can learn.)
I think the “my code; my bug” thing is great because if you lead by example people will follow suit and take responsibility for their failures as well. I think that’s a great effort to move towards a more positive culture.
It's fine if you yourself want to take blame for some code you wrote. It's not fine if someone else wants to blame you for it. You wrote it, but someone else reviewed it, and (probably) still someone else tested it and yet someone else released it. It's a team effort.
That's an idealised position, but not always a realistic one. Having specialists who understand certain parts of a complicated system better than anyone else is often valuable. Beyond a relatively small size of project, no-one can be an expert on everything, and a "shared code ownership" strategy where all code is communally maintained may leave you with no true expert when you need one.
The underlying problem here wasn't really that someone "owned" that code, but that when someone else did have a useful suggestion to make, politics overrode technical merit. Clearly that had been happening for a long time and resulted in several other potentially useful contributions by others being wasted as well. This seems to be a problem of toxic management culture, not a flaw in the technical processes.
It's not that simple. People have pride despite what they claim. If I rewrite an entire feature that someone did just because i think my way is better, you gotta be smart in how you think that should be done. Respect other people pride and work or dont expect them to respect yours.
Agreed. Of all the Agile practices, collective code ownership is possibly my favorite. It requires that one proceed thoughtfully, of course. And I think it requires other practices, like high test coverage. But I think people treating patches of code the same way dogs defending their yards is poisonous. It's hard enough to get good work done without every pull request hinging on politics.
I suggested to my engineering director that we pivot our dev effort to avoid what I thought was a pending disaster. He responded that as long as he was director he would never make the change I suggested.
Six month later the CEO replaced him and the new director announced he was going to make the pivot I had suggested. The old director resigned but advised the new director that it was not worth keeping me in the org because I was a trouble maker.
Since helping people in a position of power over you is often perceived as threatening, just let them fail and focus on moving up in a org outside their reach. I would suggest moving to the competition and working to crush your old group.
Let's also consider that the worker is not always correct, and that managers might face such advice all day long from various sources, often by highly passionate devs who also assume they are right.
In this case, it seemed that the director was 'wrong' but I don't think that there should be any inherent assumptions that an arbitrary engineers advice on pivoting is somehow the 'better' path.
Also, there's a huge difference between being 'wrong' on a technical opportunity, and 'negligence' (i.e. not doing research, observing facts) or 'malfeasance' (i.e. willingly doing the wrong thing for the advancement of self etc.)
My advice applies to the worker who has done enough research to feel confident that they've found a vastly better way that is likely to meet with resistance.
I'm just not piecing it together. The author was told:
>In the future, stay the Hell out of other people's code.
But then says:
>Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since. But those words were valuable nevertheless, and I've gone back to them time and again.
So was that advice bad and why? Or did it end up being useful, and why?
The advice was bad. But it was useful in helping him maintain perspective any time another engineer had comments about how crappy his code was. His instinct was to give them the same advice, but his brain would override reminding him of why that's bad advice to give.
It also helped him understand politics in a company, and how it gets in the way of certain types of progress.
Really? It doesn't take much to see that he used the opposite of that advice in order to make sure he was attentative to new hires insights and to criticism's about his own code.
Everytime someone comes up and says his code sucks he remembers being a young engineer admonished for making someone's code better, and instead of getting defensive, he listens.
I see how it's counter intuitive - almost seems as if the author is contradicting himself. But it did drive a point home, especially that last sentence. This is what I took away from it:
You may be able to come up with better ways to do things, but that often means replacing or voiding the efforts of coworkers or bosses. People have fragile egos, and may feel their job is being threatened since you are arranging things more efficiently. This could churn office politics, and cause problems that have little to do with the job itself (emotionally compromised workers and shifting hierarchy).
Likewise, it is our responsibility to embrace the skills of fellow workers in order to enhance workflow. There is no such thing as superiority if you're a member of a team. Kill the ego and think about constant improvement for the group
> but that often means replacing or voiding the efforts of coworkers or bosses.
Comment: Having a work environment where people up discard and replace the the work other people have done is really really bad for moral. If you let that stuff happen continually you'll end up with a team where no one cares or takes ownership of anything.
More than irony, it's a paradox: the advice was so bad that it was useful, because he had no doubt it was bad and it was received in dramatic circumstances so he will always remember to do exactly the opposite.
I stand corrected. I read and understand such devices, but it's been so long since I had to formally identify them that I just go for the basics. As an aside, as time goes on, I find myself valuing more and more the ability to read and write beyond the purely literal. The literal can be so inelegant and inefficient, but sometimes it feels like anything beyond the literal can be perceived almost as a foreign language, and if the person with whom one is communicating never learned that language, it's all Greek. I suppose its like an add-on to one's language that's learned in Literature classes, or rhetoric classes, or Classics.
In 1999 my boss's boss loved Silverstream.* It stores code in the database! Anyone still using files for code is obsolete!
We had 12 beefy servers powering our site. So I rock up and realise we're not using any of Silverstream's features, and its just acting as a servlet container. Big boss had moved onto bigger and better bossing by now so wasn't around to stop me.
After a couple of weeks of investigation, we demonstrated that Caucho Resin is better in every way. Fraction of the cost, starts super fast and runs like lightning. Great. We happily switch over and all was well for almost a week.
A few days in the head of Ops barrels up and demands to know if this was all my fault.
"Ummm, yeah?"
"Great. What the fuck am I supposed to do with the other 11 servers??"
I think they'd had to fight for budget for enough hardware to run the site with Silverstream, and young me had just made them look incompetent. They forgave me eventually...
* I actually like Silverstream's core ideas. It was just a little ahead of its time, and stored code in the db. And was 12x too slow.
It reminded me of how I once got into hot water with the Boss over introducing a binary search into their huge customer file search and update operation, which used to take three hours to run. When the program stopped in five minutes, everyone was mortified that I had broken it.
There is an entire world to be dissected in the final few paragraphs. The essence of the error the author made (and we know he made an error because he ended up in the head boss's office being chewed out) is to imagine that a successful project is founded on good technical grounds; not true, or not only at least.
The author's presumption here is that the advice was bad, and he learned the opposite lesson (don't accept social boundaries). But the advice WASN'T bad, because the organization doesn't consist of just code product, it consists of a set of programmers, managers, executives, users, customers, etc.
The important question this article raises is: WHY do people write code? What makes someone want to write good code? What motivates them to do work? What motivates them to wish to cooperate with others in their effort, to communicate their problems and insights, and contribute to the greater health of the product?
This, more than anything else, kills projects. The smartest people on earth can accomplish nothing if they petulantly refuse to cooperate, and in order to accomplish that you need to pay attention to more than what is merely technically best, you also need to pay attention to the people in your organization. What do they WANT? If they are anything like a normal human being, they want - to appear successful, to be valuable, to have their skills be seen as valuable, to have their ideas and work be appreciated by others.
We can, of course, dismiss this as "ego" or "politics", as the author does, mere cruft that gets in the way of the ur-goal of the organization, a beautiful product. But if we do so we're really ignoring what people want - and that is NOT to merely be a gear slowly ground down in the service of the greater good, eventually worn out and replaced by a newer, better gear.
Such advice, that we should ignore the very normal (and yes, egotistical) motivations of ordinary human beings at work, is perhaps not the best advice you could get.
(background: my expertise/degree is microprocessor design and digital logic, although I've done a butt-load of firmware in C and C++ in my career)
One time (long time ago) when I worked at Motorola (this was back pre-2K when working at Moto actually meant something). There was a systems level problem, and I was brought in as a systems engineer to diagnose a problem (think "big system with tons of FPGAs, fiber optics, embedded CPUs, firmware, etc.)
Pretty soon I delivered my suspicion that the real issue was a hardware problem (this after looking at network data on a capture)
The hardware director said (I wrote this down in a notebook, I'm quoting verbatim): "I stake my career that this isn't a hardware problem. It's either a firmware problem or a misunderstanding of the requirements."
It was a hardware problem. I demonstrated it a few weeks later and the chip vendor confirmed it (it could take up to 2 weeks to reproduce the problem)
After that my name was shit. That's when I learned that office politics are very fucking real, and sometimes you have to decide if you want to be a lifetime corporate employee.
I left less than a year later, hung out a shingle as a consultant and life has been great since then.
You can try to bend the world (or your employer) to your will, but it isn't going to end well. If my life goal had been "work for Moto for 40 years then retire", that wouldn't have worked out so well, for multiple reasons.
I'll always bet on myself before I'll bet on BigCo. I'm contacted every month on LinkedIn by Google, Amazon, etc. (I've trained lots of their employees) and my answer is always the same: "thanks but no thanks"
Apologies if this sounds self-aggrandizing. 100% not the intention. Just a lesson that you gotta look out for yourself, and the real world is complicated. Own your career, don't put it in the hands of BigCo. BigCo doesn't give a shit about you.
Even on a purely technical level every organization has unprovable things its members believe in. Challenging any of these openly is a surefire way to get told in office-ese to STFU noob. Quietly demonstrating that they were wrong results in at least some cognitive dissonance, with all the mental fallout that gives. Even worse, you've done this after challenging them, and everyone gets defensive. And the absolute worst, as the author experienced, is when money or ideals is at stake, and you unknowingly shift the goal posts.
I worked at a place with mostly time-limited positions as my first job, and based on what my original boss said I'm pretty sure the new boss passed over my application because of politics like these. But like the author this only strengthened my resolve to question my own and others' assumptions.
Very early in my working life I had the misfortune of doing data entry and cashier work where I significantly outperformed my coworkers. I was _hated_ in these jobs.
What I didn't realize was that the team's performance was dictated by the top performers and that _everyone_ was intentionally slowing down their work so that they could have a relaxed, easy job. By doing my best work, management set the expectation for everyone to work 10% better than that.
What I didn't understand at the time was that several of the folks in that job were lifers and they'd realized quickly that the compounding interest of always having to perform 10% better every month would break them. My eagerness to do good work was quite literally ruining their lives.
My take away lesson from this was to always try to work someone with people who are more skilled and more ambitious than you are or with people who want you to help pull them forward.
If you discover a way to make the system 100X faster, and the reason is someone else's code, then tell that programmer, and only them, and tell them gently what you found and leave it with them to be the person who implements it, or offer to implement a solution together if they want to.
They may or may not take sole credit but it doesn't matter. Definitely do not sneakily try to let people know it was really you who is responsible.
Maybe Russ wasn't sneaky - especially since he said it was early in his career? Maybe he fixed it thinking everyone would 'high-five' him for the win. Unfortunately, he didn't understand the political ramification at the time.
I've tried your approach. In my experience, the outcome depends on the person who has created the mistake - not the person who fixed it. Yes, be gentle with the solution, but that will not solve the problem if the person you are dealing with does not share your sentiments.
Talk is talk - and can be easily dismissed and rationalized away.
It mightn't have been a novel idea at all to do the 'single process' but in order for it to work, someone 'had to do it'.
It might have been more prudent to 'get it going' - and then somehow socialize it very differently, maybe by inviting the other team in and 'giving them the credit'.
It depends what one's goals are. Improve the system? Build good working relationships? Make yourself or your team look good?
In many cases similar to the one you described, the other programmer has already heard what you are trying to tell them and chosen to disregard it, for reasons good or bad. You have outlined a good starting point, but if you stop pushing, you are likely going to maintain the status quo.
"They may or may not take sole credit but it doesn't matter."
If you improved something greatly then it is your credit and it matters that it was you and not someone else.
IP conflicts are a different story, one that I would like to see avoided with OpenSource becoming standard.
Considering the fix was about removing a socket connecting two independent processes I would assume the overall architecture was originally chosen to separate the work of independent teams. There would not be one programmer to talk to about this.
Politics makes me sad. My main interest in wanting to become a developer
was to have the ability to build improvements. I want the company to do well. I want the team to receive recognition. I want the people around me to be happy and to be working on a product they care about.
It's funny, because I wanted to be a developer for the exact opposite reason: to develop what I wanted, for myself not for a company.
There's few other fields where you can be this creative, where there's infinite potential and infinite niches available. Why waste it all and get tied up in politics? I sincerely thought the ability to do anything was the reason people became developers in the first place.
Communications! Don't stomp on other people to get to the top, instead get them to boost you up! Example: Make the changes to see if it works, but instead of showing it to your or his boss, you tell the one who wrote it that, "hey I got an idea on how to make this 100x faster". Only when he/she says your idea will not work, you say "actually I did test it, see". And you might get valuable information like for example the political status.
No human is perfect and people inevitably make mistakes. Including big mistakes.
Imagine this scenario. You created something very complicated that you're proud of. You spent a lot of time on it and your integrity and reputation rely on this thing you built.
Little did you know that what you built could be done in a way that is easier and 10x better. The foundation of your reputation is in shambles. What would you do?
I can tell you what I've seen from experience. The very people who tell you that bias doesn't affect them or complain about how politics always trumps technical problems are the very people who will FOLD when the same problem hits them in the face. No one is perfect and there will be a time that this happens to most people... a time when that person will be utterly and completely wrong about something they've advocated for so long.
It's trivial, easy and immature to advertise and complain about the weaknesses in other people. I want to see a blogpost about a programmer coming to terms with their own grave mistakes... their own imperfection.
Once you realize how hard is to do that, then you will know know what to do when this problem infects your work place. First and foremost you must introduce change without hurting peoples' pride. You must be empathetic and take into consideration how other people will feel if you try to pick them apart. If you take steps to do that, people will return the favor in kind. If you attack the scaffolds supporting the reputation of your peers, expect everything that you've built to be attacked as well. Remember. No one is perfect.
The original poster is as responsible for creating a toxic work place as the people he's complaining about. I'd bet he'd react the same way if the tables were turned.
What a bizarre story! Of all the people in the org chart, the "Biggest Boss of All" should be most concerned with the company bottom line, and least with protecting individual developer egos from each other. The wretchedly slow performance of the CAD system could easily have cost that organization customers. Just, wow.
The problem nowadays is that software engineering is mostly about politics - Especially in big corporations.
Corporations use extremely inefficient tools and processes but because they have a monopoly over some area of the market, they can easily survive in spite of very poor technical decisions.
What happens is that engineers who work for these companies learn a lot of bad habits and tools which slows them down; they become overly focused on risk mitigation instead of productivity.
I'm starting to think that this is intentional; corporations want their engineers to get stuck in a technological rut; that way they can't leave and start working for a startup which will disrupt them later.
Even some corporations which seem innovative, are not actually innovative at all; their entire ecosystem of tools is extremely inefficient once you step back and consider the big picture.
I think it’s more likely that in big bureaucracies management is seen as the most important function of business.
Managers see their work as “important” and not just the admin that supports the real function of the delivering product.
If you’ve ever sat in a meeting where management spent the whole time talking, instead of asking the team that does the work how could we improve our current processes, that’s what’s happening.
You’ve run smack bang into the collective ego of multilayered management.
Small startups succeed in part because the lines of communication are small. The ratio of those “ordering” the work to those “doing” the work is low and feedback is possible.
In big enterprises outsourcing looks like a great idea because value only comes from management and workers are just a cost centre. Cheap is better than expensive if you think everything is a commodity.
Depends on your model. In a small business where you have a couple experts in different domains it makes perfect sense to talk about individual ownership. It's not toxic: it's forced practicality. In larger environments with close skill parity it doesn't make sense and hurts morale.
The change made the program faster but nothing is simple. When the GUI and backend were different progresses there was memory space separation. It was impossible for a stray pointer in one to klobber the other. Also there was a protocol between the two - which could be used over the Internet.
That's what I first thought too. There's was obviously a decision to separate the processes, but the performance gain of combining them was probably more meaningful in the end...
Now that my job resembles the 'biggest boss of all' more than the young developer that I was all those years ago, I often think about what I would have said to that young man.
If it were me I would thank that young developer for all the hard work and offer a few bits of advice on getting things done without pissing people off.
And then I would get all of the leads together and have a serious talk about how we can take care of all of our people while at the same time producing the best system humanly possible.
Good developers work hard and care harder and, being human, they have egos. But everyone has blind spots and everyone
makes mistakes and the essence of a good organization is that it blends the strengths of all of its members.
> I had supplied a war winning weapon to one organizational faction and the other factions were not happy
The real problem is that there are adversarial relationships within the organization. It can be an ego issue, or perverse incentives, or conflicting departmental objectives, or short-term thinking. Anyone who doesn't spend their time focused on politics or covering their ass will still have their motivation sapped, and soon no-one will care about making the product better.
The non-dysfunctional response is "great initiative, we'll get a meeting together and discuss the pros and cons of implementing your spike."
The idea (and practice) of "code ownership" is one of the most annoying things. First of all, it creates an atmosphere of some kind of laziness and lack of responsibility on the part of the individual team members (perhaps, not all, but still) for the results of the entire team's work. It also promotes what in my view is a rather insidious habit of assuming that if someone has wrote a piece of code long ago they are still responsible for it and, moreover, they are ready to instantly answer any question about it, as if it is supposed to stay fresh in the developer's mind forever.
I also believe smart people will do dumb things from time to time - especially under the pressure of deadlines. It's always good to assume they were having a bad day.
I know what does not work - printing out a "team-mate"'s code and pinning it to your cube wall w/o even asking a question about it. That goes in the bucket of things I thought I'd never see in the workplace.
I got hired at a Fortune 250 to rewrite a system, from the ground up, that had been running for 5 years. I rewrote it in about a year and a half. Huge success; 1000 happy users.
What I learned over time was that "the" person responsible for the group that was _supposed_ to be writing this sort of software in the company had been trying, for 10 years, to make something like it, with a whole team of contractors. In fact, it was his initial failure that caused my boss to write the first version of the program. When they saw that my boss had hired me, they doubled their efforts.
Their version of the idea was total garbage. Nobody would use it. It was terribly slow, clunky, and had a fatal flaw that would have caused people MORE work than just not using their program.
The boss of their group managed to get one of his underlings moved above my boss. He told us to stop working on my program. We did. They brought it Microsoft consultants to try to make their version suck less. It didn't work.
I suggested many things to work together. Rebrand. Code features they needed. Use some of their software. Whatever. All rejected out of hand.
We BEGGED our boss to IMPLORE the other manager to AT LEAST fix the "fatal flaw" of the other version. He agreed to, but we knew he wouldn't.
We released a bug fix for production. The other manager lost his mind, and got our manager to force us to hand over the code to his group. It took them TWO YEARS to make a single change. My program happily ran like a clock during the interim.
They finally gave up on their version.
My boss was put on a PIP. I was put on the tiniest project possible (which was completely doomed anyway), and forced to write what should have been a quick and dirty web app as a corporate, Java monstrosity. (But I repeat myself.)
In my first meeting, the other manager's toady told me to my face that he was going to kill the project I was hired for. In 4.5 years, I never even met the other manager, though he sat 50 feet away from my last cube.
There was no winning. My boss was very politically savvy, and just plain nice. There was nothing he could do. I stayed completely out of it. I did the job I was hired to do, and embarrassed the wrong people. He was written up. I was put out to pasture.
You can say that I should have done things differently. Maybe. Maybe not. What it tells me is that I was in the wrong company. Which sucks, because I could have written LOB tools like this for the rest of my career there. But this sort of dimness of vision is rampant throughout the company concerning anything related to IT. According to them, the only way to write software is to follow a strict waterfall methodology, in Java, with overseas contractors.
Making the company suck to work at, and the act of wasting millions of dollars, because it helps you build a political fiefdom, is an idea that needs to be rooted out and eliminated by the C levels. Why does this not happen? Instead, one of the C's just did a "post-mortem" on this whole fiasco, and the result was that IT needs to be "more aligned" with the business, and have better "communication."
Really? That's the level of acumen of our C-levels? They can't smell the metric buttload of BS that was shoveled in that meeting? OK, then. Good luck in the future!
I start a new job on Monday. Crossing my fingers that they will be open minded. I wonder if my old company will still be viable in 10 years.
I suppose someone would say that I could have been more diplomatic, but someone needed to voice a differing opinion. Unfortunately, there was just no way -- diplomatically or otherwise -- I was going to be allowed to influence the culture or the process. Too many other people had built their careers on the back of a 30-year-old process. It was, as they say, entrenched. Sometimes, you just get dealt a bad hand, and you can't draw into a winner.
> They knew, but they kept it to themselves because in that organization, there were some things that were more important than making the system better.
Hope this isn't the best advice I ever get.
I do like that it wasn't the biggest-boss-of-all's words that mattered, but how the words made him feel: never be this guy.
I work in a small team. I occasionally find a thing or wrong in my teammates code. But instead of changing things I simply talk it out with them. Requesting them to try the change also ensures that they've their sense of ownership. It has worked nicely for me till now.
This is the fault of the higher level executives. Clearly there was no oversight, no ability to discern what's going on their teams.
And it's actually ok that there was much more spent than they planned for on something, this is the nature of development, even that there were competing ideas, even groups ... this is normal. But that there was no accountability for obviously bad actions - not good.
On a related note, can someone elaborate on the performance of using sockets. I would assume given that it's on the same machine that there wouldn't be that big of a performance hit. Especially if the data being passed was done in big chunks to avoid the overhead of whatever protocol was being used.
I know it's not the point of the article, i am just wondering about it for curiosity's sake.
It's the serialization/deserialization that gets you. And not just the actual transformation, but also the fact that you have to turn every operation into some message. What could be a fast loop to read/modify/write the bytes in some rectangle in video memory, now has to read all those bytes into a flat buffer, do the modify (probably with extra code because the layout of the mask and the layout of the buffer are no longer compatible), send through the kernel, and then get unpacked and written to video memory in the other process. For infrequent or batch jobs this might be a well-structured interface with some good robustness features. For user interfaces which should be low latency it takes 10-100x as long and for no actual benefit.
Also doing things in big chunks is more efficient, but usually adds latency.
It depends. Any IP-based socket will still go through some protocol stack (routing and filtering). On the other hand, unix domain sockets are optimized for IPC and should perform well. But any socket will require a copy, and thus be slower than shared memory.
On the other hand, if you are going to exchange json messages, you can stop worrying about socket overhead.
Even on the same machine using sockets is going to be much slower than function calls, or shared memory access. One of the criticisms of early X Windows system was its slow performance on local machines.
But the client-server design of X-Windows was quite deliberate. Makes me wonder if this CAD system had a similar pedigree? I think we’re only hearing half the story here.
Well, many systems do IPC and often this is done over sockets.
Maybe a better question is, in 2018 why don't we have much better, cleaner, simple, IPC?
If the system was slow due to this, it might have been the sheer quantity of data over the IPC/Socket. Looks like they were rendering on one side (i.e. 'making the picture') and then pushing that to a different process to rasterize, i.e. 'draw it on screen' which just seems a little crazy. I'd imagine this was probably due to some kind of legacy thing.
I think a common approach for IPC these days is to use named pipes. Chromium uses it and I've used it in one of my projects. You still have to deal with serialization and deserialization overhead but its usually pretty quick.
This is weird info right now because after an acquisition I got a big promotion on the technical ladder so that getting into other people's code and rewriting it is now a big part of my job. It's fun but I would not want to do this without a lot of management support. Also I work hard at relationship maintenance and buy-in.
It's not a programming advice. Similar counsel is dispensed in various tech, and non-tech fields, because it's about relations with other people which sometimes could be more important than efficiency for one's career, or comfort. However, to discourage from thinking about improving other programmers code, and call it "the best programming advice"? No way.
I've never worked in a software only organization. But instead in smaller teams of specialists. Usually there is an process where if you have an issue with something you work with the person who's responsible to fix it. You just do not go in and change things. You never go in and change things without telling them.
Friend of mine talking about how he fixes bugs. Most of the time he tries to figure out where the problem is and and then writes that up. Then uses blame to figure out who wrote the code and reassigns the bug to them.
Him: I Eddy, hey think there is a problem with this condition in this function.
2) If you can't accept changes to code you worked on (NOT "your code"), you're unlikely to improve.
I agree these are not absolutes. It might be that you understand the subtleties of some particular device / library / whatever much better than other people, and their changes to the code you wrote with those quirks in mind are bad because of their lack of depth. Talk to them, or better yet use meaningful names / comments in the code so that they understand why you wrote it that way.
sorry. i was not clear. i just meant to say that one need not agree or disagree with it in order to gain some value from it.
i mean, it's worth thinking about: "some people might get mad when i make a change to this unfamiliar, problematic, buggy code base. but how mad are they going to be? could my boss become angry with me? will i make any enemies? will i be a hero? will anyone even notice?"
I always worked for small companies early in my career for exactly this. The suspicion that large corporations are driven by egotistical sociopaths.
Now that I've worked for a large corporation I have proof that I was right (YMMV). Not only that, egos can become such a barrier to progress that projects within these companies become what I would consider criminally incompetent.
This article is a great reminder of how to work with others but I think it is unlikely to be received well here. Hacker News loves to dump on junior developers and hates literary subtlety. This article uses the latter to admonish the former.
Some of us don't care so much about the karma. Reactions to my posts are either extremely polarized (one way or the other) or basically neutral. I've even gotten the occasional ban threat from dang when I say something particular unpopular. Occasionally there's still some worthwhile discussion that happens here.
Although I tend to agree with you, I do think one has to keep in mind their audience. I typically don't expect to have to read programming blogs several times in order to catch the literary subtleties, whereas I might expect that reading literature or philosophy.
I did something similar once but failed to glean such a valuable lesson from the experience. My takeaway was, those people are touchy so leave their shit alone. Not because it’s right but because I’m just trying to get through my day, and i don’t need more politics in my working life. People can be assholes, it’s just how it is sometimes so let them be.
Among my own team, if I raise points or ideas that get disregarded in this manner (as opposed to more thoughtful demurrals), I let it go and don’t push the issue. I’ll speak up if I think I have something worth considering, but I’m not going to beat you over the head to see things my way.
Still, the takeaway regarding being on the other side of that table is really important. Once you start feeling that indignant reaction or “yeah right newbie”, listen harder.
I've fallen in the same trap. And you're right, you can't fight every battle. But I think the best approach is not to make it a battle in the first place. Sometimes bringing things up in the right way and with the right energy helps people be more receptive to your advice.
I don’t want to fight battles, at all. At least not in my working life but really not anywhere else either.
I’ve seen a lot and done a lot in my career, and I don’t feel I have anything to prove to anyone anymore. On the other hand I do find it enjoyable to discuss ideas in a collegial environment where people really are trying to figure out what’s best.
If we can agree on ideas as equals and proceed then great. If not, I’ll live. If someone gets mad because I had an idea to improve something I’m not going to get too twisted up about it. Life is too short for all this stuff, and it isn’t important in the scheme of things.
It's convenient to try to squeeze his story into Steve Job's mold, but in my experience, it's the A players who tend to be the most guilty when it comes to these kinds of politics.
In my company, I've worked in two departments - one full of highly intelligent folks, and the other full of mediocre ones. In the former, these kinds of politics prevailed. I recall a particular instance where one person was working on a library, and he would actively invade other teams to shut down projects that remotely resembled his - even if his library did not supply all the features the others were building, and even though he had not yet released his library.
In the latter team, people knew they were mediocre, and were much more open to learn because of it. Pointing out problems with their code never triggered their ego.
It's fair to define them that way if such people actually exist -- which they do. I've worked with some very smart people who don't have these ego problems. Some do, of course, but I wouldn't call them A people.
People whose behavior revolves around their insecurities in that way have ceased to learn and grow. If those people who are "B" players now continue being open to learning new ideas, they are eventually going to leapfrog those "A" players in skill.
I have similar experience. People known within the company as "geniuses" are most likely to get offended when you suggest an improvement to their code. The average coders will be like "yeah, whatever".
Of course, there is a difference between being a genius, and being perceived as a genius by the managers. But sometimes there are people who are insanely good at some things (and everyone knows that) while having blind spots in other things (and get extremely sensitive about them).
This article is at best half useful, and missing the other half is potentially quite dangerous (to organizations, to people's careers, etc.) What's missing is a discussion of power and power dynamics (and healthy vs. unhealthy versions of same, let alone how to work effectively in either or drive change). Partly this comes down to a failure on the author's part to care about power dynamics or look at their own power. In this case the author was able to just blindly drive change by charging in like a bull in a china shop and the only consequence to themselves was a very minor verbal admonition, that's an indication of their level of power and where they sit in the overall power structure of their org, not every dev. in a similar position would see the same results, however. Many people would have to navigate that problem much more cautiously to avoid becoming fired or ostracized.
(Edit: and indeed I see another comment in this thread about someone who did exactly the same thing as the article's author and it turned out very poorly for them because they lacked the power the author has/had.)
Additionally, the author completely ignores the value of "soft skills" and implies that all that's necessary to have a positive impact where you work is to blindly seek the technologically superior choice whenever possible, ignoring politics, power, and ego (yours and others) along the way. There's value to that, but there's also great potential for that sort of mindset to lead you astray, because it's often difficult to know "what's best" in every situation. In the article's example the pros and cons were fairly straightforward, but most of the time the situation is likely to be a lot more complex or a lot more subtle. And it may be easy to make the wrong value judgment (and consequently fight the wrong technical fight) based on ignorance.
On top of that, this story is very frustrating because it only concerns itself with technical problems. At the end of the day the organization was still just as dysfunctional as ever even though it grudgingly fixed a technical problem it found it couldn't ignore. The author helped fixed a defect in code but they did almost nothing to help fix a much larger and more serious defect in the organization they worked in.
I would not expect junior to fix large organizational issues. Not much possible.
Also, while I strongly believe in treating people with respect and using social skills to the extend one has them, sometimes the right action to take is the one that makes people angry. When your relationships make it impossible to solve technical issues, it not junior who inadvertenly fixed issue who is not displaying social skills. It is whoever feeds the power struggle between departments.
Could not disagree more. The author most probably freed the company from its dysfunctional stagnation due to some political issue. It is thanks to his ignorance that he resolved an issue, something that had to be done.
In general, staying out of other people code is a bad idea. It promotes lack of transparency and agenda proliferation. This is because the owners of the code start being a "monopoly", can work less hard, provide exaggerated estimates etc. When people know that others can read there code, maybe hack on it, make something faster or simpler -- well they work harder and tend to be more transparent.
Since the article sucked, I'll give the 2 best engineering advice I've received from 2 different senior engineers:
>Remember when you'd go to eat at a restaurant, and the kids menu has that game where 'What's the difference between these two pictures?' That is Reverse Engineering. You have a part that works, a part that doesn't work. What is different?
>"You just kind of figure it out". Not sure how to start/solve a problem. Figure it out. This means researching, doing math, proving, and testing. And as I've done this more and more, math is really really useful to prove things.
> “Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since. But those words were valuable nevertheless, and I've gone back to them time and again.
Every time some annoying new-hire comes to me with a dumb idea that is obviously not going to work, Stay the Hell out of other people's code plays back in my head and I listen harder.
Every time some other engineer has an opinion about my code, I remember what I thought of the idea that you should mind your own technical business and I try to disengage my ego.”