I work with software.

I am not the most senior of devs, but I'm also no longer very junior either. Looking back, I see my own evolution and progress, skills-wise. I can confidently take on much larger tasks than I could a few years ago.

I have reached a point where I feel it is important to lay down a strong ethos for my work. I think this is a part of doing a professional job. Unfortunately, this means there are constraints on how I work. Examples of principles that are included in this ethos are things like:

  • When I say something is done, it means it's tested and works. It's not broken. (testing constraint)
  • When a project grows, the ability to modify the software does not decrease (architectural constriant)
  • I will not lie about, or obfuscate, deficiencies/bugs in the software, because it's convenient. This has happened before, by omission, done by manager to client (social/ethical constraint)

I communicated my thinking to my direct superior. This went worse than I expected. It was explained to me that they actually have a word for this, brown code, which is code/feature/system/project that is dubious, but shippable. According to my boss, this is essentially a necessary evil, and everyone does this.

Although the conversation wasn't hostile, I walked away with the impression that my superior considers all this ethos-stuff a problem. It will eat a bunch of time, it will slow me down, and it's better to just keep cutting corners and keep shipping brown code.

Most of the senior people have backgrounds in other areas than tech. Dare I say, all but one. Most of the have never written a line of code, by their own admission.

I feel like there is risk to my reputation here. I would like to produce code that I myself would like to work with. A variation on the Golden Rule.

Explaining again, that quality now means speed and confidence later, seems pointless, I've made my point ten times by now (in various settings), it doesn't stick. More explaining will not work!

I've also explained that I'm not forcing this on others, these are constraints I put only on myself.

How can I keep the company happy, yet not sacrifice a high level of professionalism? Should I forego this ethos-stuff? Or should my attitude be 'I'm a soldier, I do what I'm told'? Or am I being unreasonable?

What should I do?

  • @JoeStrazzere Yes, I've encountered situations where boss says OK, client says OK, and later it turned out that the software was full of bugs and basically unmaintainable. I was somehow made 'lead' after the fact, for a team of three. I held a meeting with the poor devs that were taking over the project. I felt so ashamed and humiliated. I want to NEVER be in this situation again. I feel that this might keep happening unless I take a stance. BUT MAYBE THIS IS WRONG! I'm going insane thinking about all this stuff!
    – user123557
    Commented Apr 9, 2022 at 11:02
  • The above was a while ago now, but I fear this situation every single day.
    – user123557
    Commented Apr 9, 2022 at 11:03
  • Going insane thinking about this means that it is time to find another place - one where you don't have the pressures that are driving you to think this way. You might also talk to a mental health professional / career advisor about how to handle pressures or find a different kind of work.
    – David R
    Commented Apr 9, 2022 at 14:39

6 Answers 6


The problem is not the ethos. It's the fact that you feel the need to share it rather than just do it.

Explaining things like that which don't apply to others is meaningless to them, and confusing. They will wonder what your agenda is. You want to do a good job from now on? What were you doing before? Are you making some sort of vague complaint? Are you expecting praise? Are you stoned?

  • 1
    The problem with 'just do it', is that it leads to questions about why I spend my time on seemingly unimportant things.
    – user123557
    Commented Apr 9, 2022 at 8:46
  • 9
    At which point you explain why you did something in a specific and professional manner without all the fluff and philosophy. Plus how would they know the specifics of what you're doing if they don't code?
    – Kilisi
    Commented Apr 9, 2022 at 9:03
  • 1
    Just say the cost of fixing bugs is much higher than the cost of spending an extra hour making it bug free and scalable to begin with: coderskitchen.com/cost-of-fixing-vs-preventing-bugs Commented Apr 12, 2022 at 13:36
  • note that the post you link to is talking exclusively about bugs. It's entirely possible to create an unmaintainable mess that has few bugs, but is a nightmare to change in any way without introducing them. Scalability is not touched on in the link, but is related to that. It's not as simple as "less bugs" = "quality code" at all
    – bytepusher
    Commented Apr 12, 2022 at 23:48

It's unlikely your stance is going to change the business practices. If it only happens once in a while, perhaps you can just learn to tolerate it. If not, you may need to find a new company that shares your personal ethos.

In many companies there is often tension between "the business needs this shipped" and "I want more time to do it (test more, make it more maintainable, design better, etc, etc.). The good companies learn to get to "good enough".

I completely agree with refusing to " lie about, or obfuscate, deficiencies/bugs in the software". But the decision regarding what is "good enough to ship" is a business decision, not a technical decision. You report the bugs and their impact. The business decides what to do about that information.

Ultimately, your personal ethos is yours to hold. You get to decide if the company meets your personal ethos needs or not.


I'll refer to a comment you added to another answer:

The problem with 'just do it', is that it leads to questions about why I spend my time on seemingly unimportant things.

This is exactly the problem. You (as an employee) value something else than your company. You value your code to be clean, testable, maintainable, etc., your company seems to value delivery above all, even if that means delivering a product you might not be proud of. Heck, even they might not be proud of either (a necessary evil as you wrote), but it's working for them right now, so there is no reason to do things differently.

When pain points will show up, only then will they be addressed. What you want to convince them of, doesn't seem a problem for them. So it's not being addressed. And no amount of convincing attempts from your side will work. If it ain't broken, don't fix it... where broken means different things to different people. And with various level of magnitudes too (you don't know what's happening overall and under what pressure of delivering they might be, or how contracts were negotiated, or many other reasons that might be considered more important than what you want to do to be more professional).

You have basically three options:

  • if you can't beat them, join them. Just do what you are asked of even if you don't agree with it. You were hired to do a job, so do the job. But there is a problem here. Like I said above, this seems to go against what you value. You might become bitter every day while you are doing something you don't want to be doing.
  • leave! Consider this a lesson to be learned and move on. Find a company that values the same things as you do, then work for them instead.
  • stay but try to bring in the change you want to see by being a model. Do things better. Be professional. As much as you can given the constrains you have and the understanding of others. Basically bring in change little by little without impacting what's expected of you (in your words, being a soldier and doing what you are told). It's not clear if you work alone or you have other developer teammates, but with time people might see the benefits of what you are doing and adoption will grow, which is better than for them trying to imagine what you are talking about right now.

The last point will take a lot of time with no guarantee that it will actually work. Wars are not fought by just one soldier. So think well and decide on a cut off point where you will give it up and think about the other options.

According to my boss, this is essentially a necessary evil, and everyone does this.

This is a reality of the IT industry, but I wouldn't say it's a necessary evil. You will find companies that follow best practices and value quality in their products, and you will find companies that deliver s#it simply because that works for them and they might have no competition to force them to start thinking about quality. You will see large companies with many resources that can invest in being better, and you will see small companies that have to wing it and throw non-essential things overboard just to make sure they are still around next month. And you will find anything in between for various other reasons (if you'll forgive the shameless plug, I've written at length about it some place else).

At the end of the day, the concept of Cultural Fit is important. This is a fancy (lately a buzzword) term, that means that you can't fit a square peg through a round hole. If things are misaligned between the company and its employees, the employees usually quit or the company fires them. If you can shape-shift, you will survive in the company, if not, then not. It depends on you what you want to do.

And last, but not least, I need to mention trade-offs. Trade-offs are the necessary evil. Building software is complex and inevitably there are trade-offs involved. Shipping products can't be done without trade-offs. If you want to build perfect software, you will never ship because there will always be something to do to make it better. If you deliver s#it as fast as possible your clients will eventually give up on using your product so it will be pointless also. Things need to fall some place in the middle. How does that middle look for you and your company?


Sadly, if your boss wants you to write poor-quality code, and that is an accurate reflection of the company ethos, then that is what you have to do. You can tweak the approach slightly to make it a bit better, but you will never be able to achieve the code quality that you'd like.

The puzzling aspect of this question is the implication that you have worked in this role for some time, but have suddenly seen the light with regard to the quality of your work. Presumably your manager was equally surprised; you were beavering away nice & productively, then suddenly acquire a Code Conscience from somewhere, and they must wonder what is behind this - is this a not-so-subtle way of asking for a promotion, and/or a pay increase?

I think you need to let the matter rest for a while (to calm your bosses' fears) then select a few simple issues that will improve quality, without expending too much time, and quietly introduce them with minimal fanfare. If that goes well, then who knows, you may get official blessing to do more of the same - but start with baby steps, for fear of spooking the management again.

  • This Code Conscience didn't show up in this form immediately. Over time, my perspective has shifted from 'if boss says OK, its OK' to 'I'm responsible for the product I produce. I should not blame boss/culture/company if it's trash'. I see this as a 'personal responsibility'-thing. I'm totally open to this being wrong, but sadly, I think I lack the industry experience needed to answer if this is the right attitude? How would one know?
    – user123557
    Commented Apr 9, 2022 at 10:09
  • Important thing here is that I have no stated specific obligations other than 'work on company and client projects'. I'm having a hard time understanding how to interpret this. When I ask, the answer is "Do as much as possible, as well as possible". So I get all confused! How do these things usually work out?
    – user123557
    Commented Apr 9, 2022 at 10:40
  • I encountered a similar attitude to software quality in a company that made all of its money from selling hardware; small amounts of software were needed to make the sales, but they were low priority, as they were given away free, so didn't contribute to the company's profits. When I created some successful sales-worthy software products, then the company attitude altered a bit, but software was always a second-class product, even when we made a substantial profit for the company - the hardware-first attitude was very deeply ingrained.
    – jayben
    Commented Apr 9, 2022 at 12:43

From personal experience, the problem with enforcing constraints on yourself like this - particularly if you're not the sole developer on a project - is not everybody working on the project will have the same goals/ethos as you.

Eventually you'll end up with a mix of your 'perfect' code and other people's 'brown code' - especially if your seniors are not enforcing this. These things usually have to come from the top-down and apply to everyone.

Looking to create only perfect code will only lead to frustration and demoralisation down the line. Do you what you can for yourself to keep yourself happy but don't expect everyone to agree / approve.

  • A system is only as strong as the worst code. A mix will have the bugs of the worst part - and the team will be held responsible for all of it.
    – David R
    Commented Apr 9, 2022 at 14:36

I am a software engineer with 30+ years of experience. Early in my career, in one of the first organizations I worked for, I started participating in a Software Process Improvement "club" that was sponsored by my company. It was a very large company and the SPI group was not in my immediate organization. After some time the club members began espousing the five levels of software process maturity in the Capability Maturity Model that was being marketed by Carnegie Mellon. My organization had 50 developers and we wrote some really critical software systems but the organizations CMM level was 0/5 at best. I put together a presentation and invited some of my managers. They in turn invited managers 2 and 3 levels above my organization and they all showed up. My presentation turned out to be a much bigger deal than even I had anticipated. I start my fancy presentation by introducing the topic and 30 seconds into the presentation the highest ranking executive in the room stops me and start peppering me with questions. It's immediately clear to me that this guy doesn't know why he's at the presentation. I try to lay the foundation about how his organization can improve how they build, deploy, and manage the software assets they're responsible for... And he cuts me off cold. He stands up and declares that "WE DON'T BUILD SOFTWARE!" and storms out of the meeting.

It's taken me a number of years to fully understand what he meant. It boils down to this: Very few organizations build software for the purpose of building software. Organizations are responsible for building value. Management rarely cares if the value comes in the form of software or little yellow widgets coming off the assembly line. Upper management almost never cares how an organization builds value, nor should they.

If the quality of the software being build by your organization is perceived as delivering value, you will be hard pressed to change their minds to your way of thinking. However, you might try to convince them that there is increased value to them by adopting your ethos. They may not see it but until you put it in terms of the values they understand and care about you will not change them.

And remember that value comes in the form of increased positives and decreased negatives. If you can show value in decreasing the negative aspects of what is being produced now, you may succeed.

Not the answer you're looking for? Browse other questions tagged .