26 ms·

Some hard lesson's i've realized while working in "professional" environments: 1. You must earn respect before you trash the system, no matter how shitty their

Some hard lesson's i've realized while working in "professional" environments: 1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier. 2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around. You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit. Or you can just start your own company and make your own rules.

sleazy_b 8y ago
"Excuses for why shitty code is in production are probably legitimate excuses" Honestly, I don't think this is true in the general case. It's certainly true that there are times when deadlines mean code quality is going to suffer, but I think the incidence of this is probably lower than the frequency with which this is used as an excuse.
- Retric 8y ago
  I find the common cause of bad code is changing requirements. If someone is given the choice of a change that takes 1 hour or 1 week it's very hard to stick with clean code. Make a change and then undo it more than once, and it's easy to leave a few if (false) bits hanging around that don't break anything today. Next biggest issue is a changing team. If you don't really understand some bit of code it's often safer to code around it than mess with it.
- coldtea 8y ago
  If the code works and produces money for the company, no excuse is needed. Perhaps the founder had better things for his time than perfecting some code that was already good enough to get clients/VC money.
  - tremon 8y ago
    If the company expects continuing maintenance and feature additions to that same code, then yes, a better excuse is needed.
    - coldtea 8y ago
      Sure. But they can pay someone to fix their mess when that time comes. It's a "nice problem to have" kind of thing.
  - krapp 8y ago
    That attitude makes sense, initially. But continuing to ignore code quality (and potential security issues) and blindly piling on complexity and feature creep and hoping for the best is just playing Russian roulette with your money.
- AnIdiotOnTheNet 8y ago
  In my experience it is almost always the case. I think this is a case where Dunning-Kruger* often applies, which is to say that you enter this new environment and think you know what's going on only because you're so completely ignorant of the details. Other times it's simply that decisions were made that made sense at the time and only look stupid with the benefit of hindsight. In either case, that bad code probably still exists in production for a very legitimate reason: the trouble it causes isn't worth the cost to fix it. *I'm aware that DK doesn't really say what the common interpretation says it does
  - notabee 8y ago
    Another concept that complements this is the fundamental attribution error. It's called that for a reason. Instead of first assuming that everyone who came before was a terrible coder/worker/person, you have to look at the context and incentives at play.
- markstos 8y ago
  There is no general answer. In any given case, you don't know. Just you would like for people to assume you have the best intentions and reasonable practices, you should also provide some respect to the developers of the original code and not assume what you see in production is necessarily their best work or the way they would do things now.
purple-again 8y ago
Cash Rules Everything Around You. The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it. I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.
- aaomidi 8y ago
  You fired for someone finding bugs in your code? This is beyond ridiculous and you're creating a hostile environment for your developers. It'll come back and bite you in the future.
  - Cthulhu_ 8y ago
    He was fired for doing an unsolicited code review, which the grandparent did not ask for nor deemed necessary. Plus the wording implies the grandparent felt attacked - as the thread earlier mentioned, you shouldn't barge in and go all Steve Jobs and yell THIS IS WRONG! THIS SHOULD BE FIXED! right off the bat. I do understand it though, and when you're fresh in a project it's easy to go for the low hanging fruit like that. But, be subtle about it, ask if it's welcome, that kinda thing.
    - toomanybeersies 8y ago
      What the hell is an unsolicited code review? When you start work with a new codebase you spend some time to get acquainted with it. It only makes sense to take notes of bugs or possible improvements when you do it. A pair of fresh eyes will always find improvements to be made.
      - aaomidi 8y ago
        This so much. If you expect me to take on a project without looking at the previous code then you're simply a fool.
toomanybeersies 8y ago
I've luckily managed to pick up on these lessons without learning the hard way. At my current job, the quality of the codebase is frankly, quite shit. The unit testing coverage is fine, but the actual quality of the code isn't good. It's not clean, there's a lack of separation of concerns, it's poorly formatted. Within the first week of starting the job, I had a laundry list of things that we should do to clean up the codebase. However, I've been slowly feeding this list to my manager, rather than just dumping it on him.
kirykl 8y ago
Forcing a new "unrespected" hire to engage in a broken system is such wasted potential. These are maybe the only people who can change the system for the better. Their unfiltered view can help identify inefficiencies in ways entrenched workers cannot. But instead companies force the most manual, annoying processes no one wants on them, until they are crushed by the weight of status quo and become part of the problem.
- reitanqild 8y ago
  Letting new people who don’t thoroughly understand the old system write a new one seems like a recipe for another broken system.
  - kirykl 8y ago
    My point is that companies should welcome the feedback, facilitate and encourage it. Not that new people should re-write a new system
    - majormajor 8y ago
      I agree completely with this, but getting back to the human factors: - It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus" - the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap." The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."
      - compiler-guy 8y ago
        A lot of times if you say, "I'm having trouble understanding how module X does Y, and why it works that way." And the developer will say, "Yeah, I kind of hacked that together when the requirements changed. In a perfect world, it would get rewritten, but I've had a bunch of other things higher priority." So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.
snowwrestler 8y ago
I will add that, as a new employee, the best possible way to gain the trust of your new managers is to make them look good. In the case where you can see some obvious improvements, that means working collaboratively with the manager so that they can take some credit for the improvements. Specifically it means offering criticism and suggestions privately, getting the OK before making changes, and letting the leader manage the broader communication about the changes. This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above: > Or you can just start your own company and make your own rules. When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that. In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them. If they are total assholes, you don't want to work there anyway. But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.
- reitanqild 8y ago
  > It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. Also worth pointing out: Sometimes (often) the people who are most vocal about this are not the best coders :-)
  - 8y ago
shortoncash 8y ago
Your #1 is so true. The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen. Now I just put a mental crosshair on the code I want changed and come back to it.
- fhood 8y ago
  Ditto. Not only that, but when working with a large codebase, design decisions that seem unfathomable at first glance often turn out to be reasonable or necessary once you understand the code and its use cases.
- fwdpropaganda 8y ago
  #1 might be common, but surely is symptomatic of something negative. Like fragile egos.
- TearsInTheRain 8y ago
  Cmd + f TODO :shudder:
  - Clubber 8y ago
    Hah. And that's probably only 10% of what really needs to be done.
- 0xdeadbeefbabe 8y ago
  But "technical debt" may also means he didn't do it in your preferred way. This double meaning really bothers me. It's like technical debt.
  - hinkley 8y ago
    I’ve become more aware (again?) lately of the differences between ugly code and debtful code. When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory. You pingpng around and when you find the problem you can’t remember why you were looking for it. Then there’s code where you say “ugh”, take a breath and keep going. If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues. That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.
crdoconnor 8y ago
>Or you can just start your own company and make your own rules. People need to stop saying this. It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups. The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things. Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules". I wasn't. My runway would have been about 10,000x shorter than his.
- OtterCoder 8y ago
  If an expat from India, out of his element and native country, with no education or financial backing besides a punishing loan, can run a profitable 7-11, you can run a business too.
  - deleted 8y ago
    [deleted]
  - Terr_ 8y ago
    > > > Or you can just start your own company and make your own rules. > can run a profitable 7-11 Which is anything but the kind of business where you "make your own rules." 7-11s are a type of business known as a "franchise". To get an idea what that means, just see the company's FAQ [0]: > 7‑Eleven provides a fully stocked, turnkey operation [...] obtains and bears the ongoing cost of the land, building and store equipment [...] pays for the water, sewer, gas and electric utilities [...] pays for any building rent and real estate taxes [...] provides financing for all store-operating expenses [...] provides bookkeeping, bill paying and payroll services for store operations [...] provides a support structure and business consultant who meets with the Franchisee weekly to help maximize store performance. TLDR: It's not a relevant example because it isn't the kind of empowerment (or risk) we're talking about. [0] http://franchise.7-eleven.com/franchise/faq http://franchise.7-eleven.com/franchise/faq
  - 8y ago
WhyNotHugo 8y ago
> Product managers/sales/marketing do not care about your unit tests Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it. It's our job as developers to explain the importance of unit tests, and why they're non-negotiable. Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).
- talmand 8y ago
  >> non-negotiable Sure.
- knightofmars 8y ago
  Yes. This is the difference in perspective between a company founded by a technical person (or someone who has a competent technical "right hand") and one founded by a non technical person. A company can succeed for many years, 10+, with a non technical person. At some point the decisions made and the shortcuts will start to catch up. Having worked on legacy code bases with version control you start to see patterns. While there are definitely those decisions made because they were required at the time there are also definitely those individuals who obviously were out of their depth or were willing to "hack it" to get it to work. And a lot of times, they are lauded as being "A+ top producers" when the reality was they just did it faster than everyone else because they didn't think about long-term quality. The story version, I see in terms of manufacturing. If I was working with a parts supplier and asked for them to deliver a part I needed. The requirement was as fast as they could do it. They make good on the delivery. From a business perspective everything is great. We're making sales and we met our deadlines. The supplier was great in helping us out. Suddenly three years into our five year warranty parts from the supplier start failing (performance problems and fragile releases). It becomes obvious there's a major quality problem in the parts that were manufactured. We talk to the parts supplier but they've gone insolvent (the software engineer left the company). Suddenly we need to hire a new parts supplier (a new software engineer with years of experience) to rush the replacement parts that are required to meet our warranty. Which, (hopefully) having learned our lesson are paying the higher rate (proper compensation and reasonable time for quality) to guarantee a quality replacement part to prevent the loss of profits of another round of extended warranty replacements. At this point the company has just cost itself both monetarily and potentially in reputation by making the original decision to fast-track production to "get to market". I recognize that the scenario above isn't software. It's a physical thing that's gone out into the world out of the control of the company that created it. But fundamentally the same trade-off of "deliver it now" vs "deliver it right" is made. And often made by people who don't never consider the long-term costs (technical debt) because "that's not now, that's in the future". And people will often rationalize their decisions in these situations. The often spoken: Over confidence "That happens to other companies, we'll be successful." Lack of understanding "I don't care about the outcome, we need it now." Individual worship "John said we could do it, so we're doing it." Punting "We'll deal with it once we have slack time."
raphar 8y ago
This is key. I see that there are two aspects of this story: 1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process. 2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge. That said, I agree that it was better for him to leave.
- bartread 8y ago
  > Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. Well, he sucked in that team. It's good to know the kind of person you are. I've learned, somewhat the hard way, that I become a bit of a nightmare in situations where I can't make a difference quickly. This tends to lead me away from very large, very process-driven, very political organisations, because I simply don't have the temperament for it, and towards smaller, scrappier companies, where it's possible to make forward progress quickly. One day, after all, I will die. I don't want to have spent too much time between now and then having to deal with torrents of organisational bullshit. The fact that I don't know how much time I have left only adds impetus to cut through the nonsense. Whereas some people can survive, and indeed thrive, in that kind of environment. They have the patience to see it through, and gain their satisfaction in other ways than merely seeing the product taking shape quickly.
  - cryptonector 8y ago
    Right. OP was providing leadership. Sometimes that means stepping on others' toes, and how they react is key. That team was a problem anyways.
    - schraeds 8y ago
      Maybe that's the problem; he wasn't hired or looked to as a leader, or as previous commentators have said, he hadn't earned the respect of the team yet.
eeZah7Ux 8y ago
> 1. You must earn respect before you trash the system This is a symptom of an entrenched workforce and quite a red flag. Juniors have to prove themselves - other should not: that's what interviews, CVs and experience are for.
- nmcfarl 8y ago
  I've seen great CVs document excellent experience for poor performers. And I've also seen great coders dissolve before my eyes (in the face of personal problems) and turn into very poor performers that routinely caused short and long term technical problems. I don't think you just need to earn respect when you join an org - I think you need to deserve the respect you earn, and work to maintain it.
- notacoward 8y ago
  > This is a symptom of an entrenched workforce and quite a red flag. No, it's a sign that many domains are full of hidden constraints and pitfalls. For example, it's easy to nit-pick a distributed storage system (such as the author seemed to be working with) as too slow and complex, until you actually learn about the consistency/recovery/etc. corner cases that make a simplistic "just do this" proposals non-viable. You could say that's a failure to document the requirements or design. You could also say that people shouldn't need to document things that are considered baseline knowledge in their domain, and that maybe you do need to show some understanding of the complexity before you seek to do away with it (cf. Chesterton's Fence).
vincentmarle 8y ago
> You have to realize a team that's been there before you has done things in certain ways for certain reasons This is a fundamental insight that a lot of people don’t seem to get. I always refer to this quote to drive home the same point: “There is no such thing as a dysfunctional system, because every system is perfectly aligned to achieve the results it currently gets.”
- starpilot 8y ago
  This is what I think every time I see the JavaScript programmers on HN critiquing SpaceX or other aerospace system designs from their swivel chairs.
- kazinator 8y ago
  Sometimes those reasons, unfortunately, do have to do with the fact that they are actual imbeciles. If you want to be likeable among imbeciles, then you have to emulate one. When in Rome and all that.
- secabeen 8y ago
  When developing and documenting systems, I find it's really important to document Why you are doing things a certain way. What is done, and how its done can often be discerned from looking at the current implementation, but why needs to be explicitly documented.
fred_is_fred 8y ago
Failing to do #1 makes you The Ugly American [1], which has always been my analogy for it. [1] https://en.wikipedia.org/wiki/The_Ugly_American https://en.wikipedia.org/wiki/The_Ugly_American
jjtheblunt 8y ago
Well said! I think another equivalent "coping strategy" is realizing less than dependable designs often arise "organically" like weeds in an unkempt (code) garden, which involves no malice, might just involve being busy from being, as you noted, in production.
deepaksurti 8y ago
>> You must earn respect before you trash the system True, but in addition to that and I guess more important is to get the mandate to do that from the upper management. Make that mandate a part of your job role. Then whether the team likes it or not, truly respects you or not, an official mandate makes it doable. The other side is while for very practical reasons teams create all kinds of debt to move forward, we also tend to settle into a working mode using the adage of don't fix if not broken, which can be very expensive if you need to scale or pivot, and this just does not apply to start ups. Most big companies that sink I think is because they have created all sorts of invisible debts and there are people who might have fixed it, but their passion not backed by a mandate never lets it get fixed!

sleazy_b 8y ago

"Excuses for why shitty code is in production are probably legitimate excuses" Honestly, I don't think this is true in the general case. It's certainly true that there are times when deadlines mean code quality is going to suffer, but I think the incidence of this is probably lower than the frequency with which this is used as an excuse.

Retric 8y ago
I find the common cause of bad code is changing requirements. If someone is given the choice of a change that takes 1 hour or 1 week it's very hard to stick with clean code. Make a change and then undo it more than once, and it's easy to leave a few if (false) bits hanging around that don't break anything today. Next biggest issue is a changing team. If you don't really understand some bit of code it's often safer to code around it than mess with it.
coldtea 8y ago
If the code works and produces money for the company, no excuse is needed. Perhaps the founder had better things for his time than perfecting some code that was already good enough to get clients/VC money.
- tremon 8y ago
  If the company expects continuing maintenance and feature additions to that same code, then yes, a better excuse is needed.
  - coldtea 8y ago
    Sure. But they can pay someone to fix their mess when that time comes. It's a "nice problem to have" kind of thing.
- krapp 8y ago
  That attitude makes sense, initially. But continuing to ignore code quality (and potential security issues) and blindly piling on complexity and feature creep and hoping for the best is just playing Russian roulette with your money.
AnIdiotOnTheNet 8y ago
In my experience it is almost always the case. I think this is a case where Dunning-Kruger* often applies, which is to say that you enter this new environment and think you know what's going on only because you're so completely ignorant of the details. Other times it's simply that decisions were made that made sense at the time and only look stupid with the benefit of hindsight. In either case, that bad code probably still exists in production for a very legitimate reason: the trouble it causes isn't worth the cost to fix it. *I'm aware that DK doesn't really say what the common interpretation says it does
- notabee 8y ago
  Another concept that complements this is the fundamental attribution error. It's called that for a reason. Instead of first assuming that everyone who came before was a terrible coder/worker/person, you have to look at the context and incentives at play.
markstos 8y ago
There is no general answer. In any given case, you don't know. Just you would like for people to assume you have the best intentions and reasonable practices, you should also provide some respect to the developers of the original code and not assume what you see in production is necessarily their best work or the way they would do things now.

purple-again 8y ago

Cash Rules Everything Around You. The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it. I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.

aaomidi 8y ago
You fired for someone finding bugs in your code? This is beyond ridiculous and you're creating a hostile environment for your developers. It'll come back and bite you in the future.
- Cthulhu_ 8y ago
  He was fired for doing an unsolicited code review, which the grandparent did not ask for nor deemed necessary. Plus the wording implies the grandparent felt attacked - as the thread earlier mentioned, you shouldn't barge in and go all Steve Jobs and yell THIS IS WRONG! THIS SHOULD BE FIXED! right off the bat. I do understand it though, and when you're fresh in a project it's easy to go for the low hanging fruit like that. But, be subtle about it, ask if it's welcome, that kinda thing.
  - toomanybeersies 8y ago
    What the hell is an unsolicited code review? When you start work with a new codebase you spend some time to get acquainted with it. It only makes sense to take notes of bugs or possible improvements when you do it. A pair of fresh eyes will always find improvements to be made.
    - aaomidi 8y ago
      This so much. If you expect me to take on a project without looking at the previous code then you're simply a fool.

toomanybeersies 8y ago

I've luckily managed to pick up on these lessons without learning the hard way. At my current job, the quality of the codebase is frankly, quite shit. The unit testing coverage is fine, but the actual quality of the code isn't good. It's not clean, there's a lack of separation of concerns, it's poorly formatted. Within the first week of starting the job, I had a laundry list of things that we should do to clean up the codebase. However, I've been slowly feeding this list to my manager, rather than just dumping it on him.

kirykl 8y ago

Forcing a new "unrespected" hire to engage in a broken system is such wasted potential. These are maybe the only people who can change the system for the better. Their unfiltered view can help identify inefficiencies in ways entrenched workers cannot. But instead companies force the most manual, annoying processes no one wants on them, until they are crushed by the weight of status quo and become part of the problem.

reitanqild 8y ago
Letting new people who don’t thoroughly understand the old system write a new one seems like a recipe for another broken system.
- kirykl 8y ago
  My point is that companies should welcome the feedback, facilitate and encourage it. Not that new people should re-write a new system
  - majormajor 8y ago
    I agree completely with this, but getting back to the human factors: - It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus" - the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap." The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."
    - compiler-guy 8y ago
      A lot of times if you say, "I'm having trouble understanding how module X does Y, and why it works that way." And the developer will say, "Yeah, I kind of hacked that together when the requirements changed. In a perfect world, it would get rewritten, but I've had a bunch of other things higher priority." So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.

snowwrestler 8y ago

I will add that, as a new employee, the best possible way to gain the trust of your new managers is to make them look good. In the case where you can see some obvious improvements, that means working collaboratively with the manager so that they can take some credit for the improvements. Specifically it means offering criticism and suggestions privately, getting the OK before making changes, and letting the leader manage the broader communication about the changes. This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above: > Or you can just start your own company and make your own rules. When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that. In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them. If they are total assholes, you don't want to work there anyway. But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.

reitanqild 8y ago
> It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. Also worth pointing out: Sometimes (often) the people who are most vocal about this are not the best coders :-)
- 8y ago

shortoncash 8y ago

Your #1 is so true. The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen. Now I just put a mental crosshair on the code I want changed and come back to it.

fhood 8y ago
Ditto. Not only that, but when working with a large codebase, design decisions that seem unfathomable at first glance often turn out to be reasonable or necessary once you understand the code and its use cases.
fwdpropaganda 8y ago
#1 might be common, but surely is symptomatic of something negative. Like fragile egos.
TearsInTheRain 8y ago
Cmd + f TODO :shudder:
- Clubber 8y ago
  Hah. And that's probably only 10% of what really needs to be done.
0xdeadbeefbabe 8y ago
But "technical debt" may also means he didn't do it in your preferred way. This double meaning really bothers me. It's like technical debt.
- hinkley 8y ago
  I’ve become more aware (again?) lately of the differences between ugly code and debtful code. When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory. You pingpng around and when you find the problem you can’t remember why you were looking for it. Then there’s code where you say “ugh”, take a breath and keep going. If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues. That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.

crdoconnor 8y ago

>Or you can just start your own company and make your own rules. People need to stop saying this. It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups. The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things. Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules". I wasn't. My runway would have been about 10,000x shorter than his.

OtterCoder 8y ago
If an expat from India, out of his element and native country, with no education or financial backing besides a punishing loan, can run a profitable 7-11, you can run a business too.
- deleted 8y ago
  [deleted]
- Terr_ 8y ago
  > > > Or you can just start your own company and make your own rules. > can run a profitable 7-11 Which is anything but the kind of business where you "make your own rules." 7-11s are a type of business known as a "franchise". To get an idea what that means, just see the company's FAQ [0]: > 7‑Eleven provides a fully stocked, turnkey operation [...] obtains and bears the ongoing cost of the land, building and store equipment [...] pays for the water, sewer, gas and electric utilities [...] pays for any building rent and real estate taxes [...] provides financing for all store-operating expenses [...] provides bookkeeping, bill paying and payroll services for store operations [...] provides a support structure and business consultant who meets with the Franchisee weekly to help maximize store performance. TLDR: It's not a relevant example because it isn't the kind of empowerment (or risk) we're talking about. [0] http://franchise.7-eleven.com/franchise/faq http://franchise.7-eleven.com/franchise/faq
- 8y ago

WhyNotHugo 8y ago

> Product managers/sales/marketing do not care about your unit tests Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it. It's our job as developers to explain the importance of unit tests, and why they're non-negotiable. Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).

talmand 8y ago
>> non-negotiable Sure.
knightofmars 8y ago
Yes. This is the difference in perspective between a company founded by a technical person (or someone who has a competent technical "right hand") and one founded by a non technical person. A company can succeed for many years, 10+, with a non technical person. At some point the decisions made and the shortcuts will start to catch up. Having worked on legacy code bases with version control you start to see patterns. While there are definitely those decisions made because they were required at the time there are also definitely those individuals who obviously were out of their depth or were willing to "hack it" to get it to work. And a lot of times, they are lauded as being "A+ top producers" when the reality was they just did it faster than everyone else because they didn't think about long-term quality. The story version, I see in terms of manufacturing. If I was working with a parts supplier and asked for them to deliver a part I needed. The requirement was as fast as they could do it. They make good on the delivery. From a business perspective everything is great. We're making sales and we met our deadlines. The supplier was great in helping us out. Suddenly three years into our five year warranty parts from the supplier start failing (performance problems and fragile releases). It becomes obvious there's a major quality problem in the parts that were manufactured. We talk to the parts supplier but they've gone insolvent (the software engineer left the company). Suddenly we need to hire a new parts supplier (a new software engineer with years of experience) to rush the replacement parts that are required to meet our warranty. Which, (hopefully) having learned our lesson are paying the higher rate (proper compensation and reasonable time for quality) to guarantee a quality replacement part to prevent the loss of profits of another round of extended warranty replacements. At this point the company has just cost itself both monetarily and potentially in reputation by making the original decision to fast-track production to "get to market". I recognize that the scenario above isn't software. It's a physical thing that's gone out into the world out of the control of the company that created it. But fundamentally the same trade-off of "deliver it now" vs "deliver it right" is made. And often made by people who don't never consider the long-term costs (technical debt) because "that's not now, that's in the future". And people will often rationalize their decisions in these situations. The often spoken: Over confidence "That happens to other companies, we'll be successful." Lack of understanding "I don't care about the outcome, we need it now." Individual worship "John said we could do it, so we're doing it." Punting "We'll deal with it once we have slack time."

raphar 8y ago

This is key. I see that there are two aspects of this story: 1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process. 2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge. That said, I agree that it was better for him to leave.

bartread 8y ago
> Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. Well, he sucked in that team. It's good to know the kind of person you are. I've learned, somewhat the hard way, that I become a bit of a nightmare in situations where I can't make a difference quickly. This tends to lead me away from very large, very process-driven, very political organisations, because I simply don't have the temperament for it, and towards smaller, scrappier companies, where it's possible to make forward progress quickly. One day, after all, I will die. I don't want to have spent too much time between now and then having to deal with torrents of organisational bullshit. The fact that I don't know how much time I have left only adds impetus to cut through the nonsense. Whereas some people can survive, and indeed thrive, in that kind of environment. They have the patience to see it through, and gain their satisfaction in other ways than merely seeing the product taking shape quickly.
- cryptonector 8y ago
  Right. OP was providing leadership. Sometimes that means stepping on others' toes, and how they react is key. That team was a problem anyways.
  - schraeds 8y ago
    Maybe that's the problem; he wasn't hired or looked to as a leader, or as previous commentators have said, he hadn't earned the respect of the team yet.

eeZah7Ux 8y ago

> 1. You must earn respect before you trash the system This is a symptom of an entrenched workforce and quite a red flag. Juniors have to prove themselves - other should not: that's what interviews, CVs and experience are for.

nmcfarl 8y ago
I've seen great CVs document excellent experience for poor performers. And I've also seen great coders dissolve before my eyes (in the face of personal problems) and turn into very poor performers that routinely caused short and long term technical problems. I don't think you just need to earn respect when you join an org - I think you need to deserve the respect you earn, and work to maintain it.
notacoward 8y ago
> This is a symptom of an entrenched workforce and quite a red flag. No, it's a sign that many domains are full of hidden constraints and pitfalls. For example, it's easy to nit-pick a distributed storage system (such as the author seemed to be working with) as too slow and complex, until you actually learn about the consistency/recovery/etc. corner cases that make a simplistic "just do this" proposals non-viable. You could say that's a failure to document the requirements or design. You could also say that people shouldn't need to document things that are considered baseline knowledge in their domain, and that maybe you do need to show some understanding of the complexity before you seek to do away with it (cf. Chesterton's Fence).

vincentmarle 8y ago

> You have to realize a team that's been there before you has done things in certain ways for certain reasons This is a fundamental insight that a lot of people don’t seem to get. I always refer to this quote to drive home the same point: “There is no such thing as a dysfunctional system, because every system is perfectly aligned to achieve the results it currently gets.”

starpilot 8y ago
This is what I think every time I see the JavaScript programmers on HN critiquing SpaceX or other aerospace system designs from their swivel chairs.
kazinator 8y ago
Sometimes those reasons, unfortunately, do have to do with the fact that they are actual imbeciles. If you want to be likeable among imbeciles, then you have to emulate one. When in Rome and all that.
secabeen 8y ago
When developing and documenting systems, I find it's really important to document Why you are doing things a certain way. What is done, and how its done can often be discerned from looking at the current implementation, but why needs to be explicitly documented.

fred_is_fred 8y ago

Failing to do #1 makes you The Ugly American [1], which has always been my analogy for it. [1] https://en.wikipedia.org/wiki/The_Ugly_American https://en.wikipedia.org/wiki/The_Ugly_American

jjtheblunt 8y ago

Well said! I think another equivalent "coping strategy" is realizing less than dependable designs often arise "organically" like weeds in an unkempt (code) garden, which involves no malice, might just involve being busy from being, as you noted, in production.

deepaksurti 8y ago

>> You must earn respect before you trash the system True, but in addition to that and I guess more important is to get the mandate to do that from the upper management. Make that mandate a part of your job role. Then whether the team likes it or not, truly respects you or not, an official mandate makes it doable. The other side is while for very practical reasons teams create all kinds of debt to move forward, we also tend to settle into a working mode using the adage of don't fix if not broken, which can be very expensive if you need to scale or pivot, and this just does not apply to start ups. Most big companies that sink I think is because they have created all sorts of invisible debts and there are people who might have fixed it, but their passion not backed by a mandate never lets it get fixed!