How to become more “pragmatic/efficient”?

Question

I am quite a perfectionist and I like elegant and lean solutions. The problem is that I notice that this is not what is valued in my company...

I've been working as a software-developer in mid-sized to large customer-projects (banking, insurance, government..) for about 5 years now. This is my first job as dev. I studied computer-science (with focus on theoretical computer-science). Since I started working I noticed, that those who learned with a more practical approach and focus on engineering are quite a lot faster in finding solutions, although I usually find their solutions to be cluttered (and everything that comes with that - hard to understand, not to the point, unelegant, etc.). I am a big fan of Unix-philosophy and feel like I have internalized software development principiles and value them a lot: DRY, KISS, do-one-thing-only, naming is important, etc...

As such, I can spend a lot (probably too much) time on a small task, and I am only happy, when I feel it is clear, reusable elegant simple... OTOH I have a big aversion to uneasy solutions and bad design. We work with old code that grew over time with different people working on it.

But I notice, that this leads to the effect that you end up writing code that looks really simple (even if it actually was really hard to get it that simple!). And then someone who reads it feels like “that took you so long?”.

I notice how I struggle keeping a lot of state and things in my head and still being precise and I am impressed how colleagues write code, that is so hard for me to understand (and once I do understand I feel like “ah, what you actually wanted to achieve is xyz - probably there was a more elegant way) and they even get it to work.

Furthermore I notice that I usually take more time than what is the estimate. When discussing with collegues, it always seems like I am not “pragmatic” enough - “don’t write perfect code, write code that is good enough. It just should solve the problem”. I notice how technical debt doesn’t matter too much, because you can compensate that with ‘customer-convincing’, which is way cheaper (and in many cases even more profitable! Like saying, “well it is complicated, it will take 5 days”, rather than saying “well, you had changing requirements, some design choices in the beginning might not have been the best, we actually should rewrite a whole lot, it will take 10 days, but on the long run you should have less bugs and new CRs should be easier to implement.”

The problem is, that with all basic metrics, it ends up looking as if I was really slow (which is actually true in the end I guess): time spent on a ticket compared to estimate, locs, numbers of tickets solved, etc...

All this makes me feel really bad. And I actually would like to be more ‘pragmatically’ skilled. Better suited for all these “agile” philosophies: getting things done, only improve when necessary, etc..

I also feel like I am slow at understanding code and seeing those “pragmatic” solutions that just get the task done, without the need of a huge refactor. I am well aware, that the code I produce in many cases is of better quality, but since the customer is concerned with what features get into the next sprint and long-term expensive quality improvements are not so easy to grasp and measure, the stuff I produce simply isn’t a good fit for the customers need. This makes me feel bad, because I am the uneasy guy who critiques the most (stupid build, shitty infra, bad code, bad design,..) but actually gets done the least...

I am convinced that writing and reading code are opposite forces: code that is easier to write, is harder to read ("basically you just copy-paste, single letter-variable names, because hey I know what it means, one huge method that does what I need", etc.) - OTOH if someone puts effort in writing ("how can I boil out the essence, let's rename this, let's factor out that", etc.)

I’ve thought about trying a product based company, with the hope, that in that environment they hate “unelegant” design as much,as I do... but I talked to a guy in a product company and he said it is more important for them to get things done rather than having perfectly clean code... so I am feeling more and more that I am just in the wrong industry...I actually almost decided that I am leaving the company (the industry?) in about 3 month.

The question is: what should I do? Where should I apply? how can I improve my way of working? Should I look for another kind of company?

Note that over time I've actually have become more pragmatic, but I tend to feel unhappy with those solutions and I also feel that I am not as good at it as others... There are a few people which I think feel something similar as I do in the company - but the vast majority doesn't.

Answer 1

what should I do? Where should I apply? how can I improve my way of working? Should I look for another kind of company?

There is always a point in every activity where you could do more, but the marginal return isn't worth the extra time and/or effort.

That is true for software development. But it's also true for planning, budgeting, gardening, cleaning, art, etc, etc. I'm not sure another kind of company would help. You could work for yourself, but you might have a hard time getting things done and making money.

You can always do more. You can always make it better. But if it doesn't get done, none of that matters. Things need to be done "enough" and then no more. Knowing where that line is within a particular industry/company/product takes time and isn't simple.

Every non-trivial piece of software ships with bugs in it - even software that spectacularly successful. And much of that software needed to ship quickly, before the market conditions or competitors rendered it moot.

If you aren't able to get your head around the idea of "good enough" or "satisficing", then it will be difficult for you, no matter what field you work in. Voltaire said "The best is the enemy of the good."

Your best bet might be to seek the advice of those who work around you - your coworkers, your boss. Find out where they call it "good enough", and try to see if you could stop yourself there as well.

I liked to order my work from most important to least important. That way, when I inevitably ran out of time, I know I did my best with the most impactful aspects. And then I moved on.

Answer 2

I am a big fan of Unix-philosophy and feel like I have internalized software development principles and value them a lot: DRY, KISS, do-one-thing-only, naming is important, etc...

These are all important and you should continue to focus on them. I think you might benefit from YAGNI though. You Ain't Gonna Need It. There is a tendency among programmers to implement things because they think it will be needed someday rather than on implementing just what they know they are going to need. For example, you are building something that requires getting from a SQL Server database. But, you think "someday we might switch to Oracle, SQLite or another database" so instead of just writing your code to get data from a SQL Server database, you try to future-proof it by writing code to be able to get it from all the other kinds of databases you can think of. DON'T DO THAT.

But I notice, that this leads to the effect that you end up writing code that looks really simple (even if it actually was really hard to get it that simple!). And then someone who reads it feels like “that took you so long?”.

As the old saying goes, it takes a lot of practice to makes something look easy. What you are doing is dead on what you should be doing. Code done right SHOULD BE easy to read and look simple and yes, sometimes it takes a lot of work to get it there.

I am convinced that writing and reading code are opposite forces: code that is easier to write, is harder to read ("basically you just copy-paste, single letter-variable names, because hey I know what it means, one huge method that does what I need", etc.) - OTOH if someone puts effort in writing ("how can I boil out the essence, let's rename this, let's factor out that", etc.)

Code is read a lot more than it is written. In any non-trivial application, it is extremely important to write code that is easy to read. Some other person should be able to get your code from source control and be able to figure out what it is doing without excessive work. float x1, x2, x3 are terrible because then you have to figure out what each one is supposed to represent and remember each time you go to use one. float salary, bonus, commissionPercentage instantly tell you what they are, are easy to remember, and with any modern IDE, take no more work to write than x1, x2, x3

I’ve thought about trying a product based company, with the hope, that in that environment they hate “unelegant” design as much,as I do... but I talked to a guy in a product company and he said it is more important for them to get things done rather than having perfectly clean code... so I am feeling more and more that I am just in the wrong industry...I actually almost decided that I am leaving the company (the industry?) in about 3 month.

You will NEVER have perfect code. If you insist on that, you will never get anything done. The trick is to find the right balance between getting things done and writing high quality code. From what I can tell, you seem to be leaning a little too far to the latter in a company that leans way too far to the former.

Finally, you seem like someone that has the makings of a really good programmer that I wouldn't mind having as a team member. I hope you don't give up and are able to find a place that appreciates quality code

Answer 3

I’ve thought about trying a product based company, with the hope, that in that environment they hate “unelegant” design as much,as I do... but I talked to a guy in a product company and he said it is more important for them to get things done rather than having perfectly clean code

You actually want to head more towards tech/industrial company rather than a product company. I currently work for a product entity and virtually anything will get sacrificed to meet the sprint goal and client deadlines. Code reviews, unit tests, error checking, etc. Oh we have piles of best practice goals and plans for best practices, it is just that they crumble when deadlines approach. And none of our deadlines are meaningfully hard deadlines with financial consequences. It is mostly about the politics, the image of meeting sprint goals, and handling the endless change that seems free because "Agile."

A friend of mine is with a product company where they routinely copy-paste and add bundles of if statements in the last few days before a deadline, as there are financial consequences to not meeting their sprint goals (which are also contractual ship dates). There are no financial consequences to the software destroying data or being horribly slow, which is why that is acceptable.

I only know one guy who works at a place where code quality is not constantly being run over by a bulldozer of a deadline (even one as artificial as the end of the sprint) and he works at one of the tech majors.

what should I do? Where should I apply? how can I improve my way of working? Should I look for another kind of company?

This depends on how much this matters to you. I am someone who is happy being rewarded for achieving objectives. Define what you want and my finding a way to give it to you is what I find fun. You want well tested highly efficient software? Sure. You want features fast? I'm fine with that too. I will tell you that you cannot have both, but fundamentally let whoever is paying me choose. Your motivations are probably different.

Your first option is to find a company where those in charge view it as important that the code be good and those companies are those were bugs are costly and thus worth eliminating. Look at industrial companies doing real-time software. A friend of mine just interviewed for an oil major where they care deeply about code correctness, efficiency, and quality because a bug could severely harm a multi-million dollar piece of infrastructure and disrupt a billion-dollar piece of infrastructure. They have 4 people code review everything (and all must be senior developers) that goes into production simply because the stakes are so high. Aerospace companies (maybe not Boeing) would also generally prioritize correctness and quality. In these companies, "pragmatism" is perfectionism, which is similar to what you already do.

Your second option is to change what you focus on. Change your goal to excellence in shipping on time or rapid feature production. Drive your perfectionism towards what the goals of management are. Be the guy who always delivers on estimates. Deliver customer requirements in record time. Be the person who allows the salesperson to go out and make absurd promises to boost revenue by being able to deliver the promises. Make your perfectionism about perfect management satisfaction.

You can try and find a balance between the two in a product company, i.e. silently trying to improve code quality and slow things down, but you will spend your time fighting every motivation in the company which drives the lack of care about code and bugs.