The Best Programming Advice I Ever Got (2012)
russolsen.com
russolsen.com
> “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.”
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.
^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.
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.
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.
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.
Or maybe I'm just getting old.
[1] "Naive" as in unaware of the ongoing office politics.
1. Nobody really knows how to do it.
2. If you have a system for doing it, you're doing the computer's job.
(Sadly I cannot find the source of this quote.)
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.
You'll have to expand on this for me, because I find this claim shocking. Who figured it out, and what did they figure out?
I know big construction projects often suffer from similar problems, and they don't seem to have figured it out.
I find it quite strange that you are not aware about how much more reliable & secure is the product of the construction industry compared to software.
In software engineering, and in IT generally, there’s a fine line between following best practices and following a cargo cult.
That's funny, your text reminded me of a colleague who discovered that the electrician she hired used the wrong cable..
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”.
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.
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.
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.
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)
Did anyone ever say why you were treated like an infectuous disease after doing something good, which would benefit everyone?
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?
You version is quite paranoid on itself - junior denied learning and shunned for a single mistake.
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...
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.
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?
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.
> 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.
[1]: https://john-millikin.com/sre-school/no-haunted-forests
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.
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).
Don't get any data out of company, I would never promote someone who got any documents out of company laptop to his own.
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.
From now on I moto “not my business”
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.
That usually doesn't result in being called to HR and asked to remove everything from one's computer.
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.
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?
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Hundred_Flowers_Campaign
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...
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.
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.
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."
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.
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.
Edit:
https://www.inc.com/wanda-thibodeaux/want-to-know-if-someone...
Googled that for ya. Get others
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.
Recently had to quit my job because of exactly this.
People will sabotage things simply because they want the useful idea to be theirs.
1. https://en.wikipedia.org/wiki/Proportionality_(mathematics)
Then I think it's safe to say that that's not the view being used in this discussion.
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.
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.
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.
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.
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.
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.
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.
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.
Not just that, they will sabotage things if it makes them more profitable, which probably happens in thousands companies worldwide everyday.
1. Get a contract.
2. Sell some crappy software to the customer.
3. Wait for them to ask for more speed.
4. Complain it's their fault because their hardware is too old.
5. Offer to either install new hardware or rewrite the software.
6. Profit!
Guess what happens if someone makes the software perform optimally at step 2.
That would require rewriting the whole application (without the artificial speed reduction part), which may be a lot of work.
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.)
This
Always make sure you understand what is being said before you respond.
I would consider toxic a work environment where somebody would talk about "my code" after it's been merged.
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.
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 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.
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.
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.)
>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?
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
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.
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.
Learned nothing.
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.
One is logic, the other is applied.
Not according to any formal or colloquial definition I've ever heard.
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.
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.
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.
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.
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.
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.
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.
"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".
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.
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'.
Sadly - sometimes orgs have to be wiped out.
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.
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.
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.
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.
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."
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.
Truly amazing...
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.
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.
The advice the author received was:
> In the future, stay the Hell out of other people's code.
However, the author goes on to reject this advice and gives some alternative advice instead.
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.
I know it's not the point of the article, i am just wondering about it for curiosity's sake.
On the other hand, if you are going to exchange json messages, you can stop worrying about socket overhead.
Also doing things in big chunks is more efficient, but usually adds latency.
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.
https://www.chromium.org/developers/design-documents/inter-p...
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.
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.
15 minutes passes
Eddy: checks in bug fix closes ticket
1) It's not your code, it belongs to the company.
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.
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?"
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.
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 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.
B players hire C players, C hire D and before you know it, you have the politics described in this article.
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.
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).
(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.
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.
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.
>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.