ManlyBread 97 days ago [-]
I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad code, so I would often open the solution later and found a pile of ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and no one is going to pay for it". Eventually you come to a conclusion that if no one cares then why should you? If any effort on your part is going to be negated by your coworkers anyway then why bother? How do you push back against a corporate culture that has been there for years and no one seemed to have a problem until you came along? Maybe it's possible when you're a senior dev that has control over a project, but as a mid level developer I've never been successful at enforcing any standard - people usually don't care because it would mean additional work and effort on their part and they still get paid the same regardless of the quality of the code.
reaperducer 97 days ago [-]
It can be very frustrating, but ultimately it's a reflection on you.

Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can.

If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them.

Like anything in life: Do the right thing, even when you're surrounded by villains.

s73v3r_ 97 days ago [-]
Better advice: Go to where they actually care about what you're doing, if you can. Otherwise, put effort into what you're doing, but don't go overboard, and absolutely never work overtime.
scruple 97 days ago [-]
Those places are basically unicorns, as far as I can tell. I have my own anecdotes, of course, and they oscillate between "we cared about code quality" and "we didn't have time." My experiences and the conversations I've had with others lead me to the conclusion that: almost all of us have deadlines that we didn't really help set, that we're always struggling to meet those deadlines, and that there is a stupid amount of money on the line that drives these decisions. And, so it goes, "get it done and ship it yesterday" is the commonality that I see.

That said, despite the frustration, I do try to hold myself accountable for writing clear and concise code as much as I possibly can and off-setting the times when I have to commit some clever hack with long-form narrative style comments.

vvanders 97 days ago [-]
I've also seen the opposite happen as well where endless feedback and getting the "perfect" architecture has almost sunk a few teams. If you take too long building the ivory tower then the market may move past you.

The thing I care about is if it's a deliberate decision made with consideration of the rest of the business of if it's driven by fear/reactionary/habit.

The former usually means that you'll try and budget in time after the crisis to fix it up, the latter tends to spiral into a complete mess that no one wants to touch after a certain amount of time has passed.

bethly 97 days ago [-]
Any team striving for a perfect architecture rather than building something that works and then seeing where the bottlenecks are isn't focused on "code quality": they are ignoring best practice in favor of intellectual satisfaction. The best software architecture is any architecture that solves the problem.
vvanders 97 days ago [-]
Yeah, there's a natural tension in this. I know I tend to wander towards the "ship it" category but yet I've found my best work was when I was paired with someone on the "correctness" side of the equation.

It forces a constant re-evaluation of your methods and reasoning on both sides which leads to something even better than the two individual approaches.

therealdrag0 97 days ago [-]
Not sure why there's a hard-no on working overtime. Not everyone finds value or fulfillment in the same way or has the same goals.

My cousin just went from being an intern at Tesla to a FTE. This group change entailed going from 11-12 hour days to 9-10 hour days. It's crazy and maybe not for everyone but he's happy there.

I work at a more chill company, but sometimes there's something I want to do on the company code base that is not asked for by any stakeholders. I'm happy to occasionally put in an extra 10% to do something that scratches my own itch. I don't see much difference between this and someone who goes home and works in their garden or plays with Arduino or tinkers on an old car.

s73v3r_ 97 days ago [-]
If they clearly don't care, then working overtime is not going to change that, and it's just going to make things much more depressing.

This is on top of the "never work for free" rule. All that does is bring down the value and respect of our entire industry.

AnimalMuppet 97 days ago [-]
Working overtime? It happens. I accept it as part of the job, as long as it's rare.

Working overtime to clean up other peoples' mess that nobody else cares about cleaning up? Hard no.

If it floats your boat, if it's a hobby to you, if you want to spend your free time on it, then sure, knock yourself out. Have fun. Feeling like you have to? No.

blechinger 97 days ago [-]
I get where you're coming from. I just did this the other day (worked through the night on something for someone else over the weekend) but I may not have if I knew someone was going to come behind me and blow it away.

Maybe what I learned from it alone would be worth the effort. Tough to say.

s73v3r_ 97 days ago [-]
All that work would still be there in the morning, or on Monday. And you'd be rested up, and far less likely to make mistakes.
nightski 97 days ago [-]
A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful.

I'm not saying code quality doesn't matter, of course it does. But there is a bigger picture and if you don't take the time to become a part of that you will not be very relevant.

adrianratnapala 97 days ago [-]
Yes it is good to understand people and the business, but you are also hinting that much of the bad code around the place is some kind of big-picture smart optimum of technical debt. vs. development velocity.

But this is unlikely if you stop to think about how humans behave. Who in an organisation has an incentive to find such an optimum? Shareholders and the board maybe; but they can only drive things by rewarding and punishing middle-level individuals. And they can only reward impact that they can see. Thus the incentives are to create visible impact which can be spun as a net gain. If that creates technical debt, then that is somebody else's problem.

sanderjd 97 days ago [-]
Yep, this is difficult, but I think it is the correct approach. To follow on: if you do this successfully and you also demonstrate technical value to the organization, you are very likely to find yourself with enough credibility to successfully advocate for (or lead) efforts toward better engineering practices.

If you do all this, and never gain that credibility, possibly due to problematic individuals at the higher levels of the organization (which you can't control), then it's probably time to move on.

zoul 97 days ago [-]
I agree, but it seems to me that being dragged down by technical debt is massively more common in our industry than missing important deals because of excessive emphasis on clean code?
ravenstine 97 days ago [-]
Our industry is pretty hilarious in this sense. In school, it's expected that you go through multiple drafts to complete an essay, and usually those who skipped that process paid a penalty. Publishing is a high speed industry, but time is still set aside for revisions and editing. These same standards seem to rarely be applied in programming, I guess because our work isn't seen as writing communication. We make computers "go". Because of that, we are too often writing and reading each others' rough drafts.
drvdevd 97 days ago [-]
Especially in a startup, but obviously in established companies as well, this will give you an idea of where it’s all headed.

If you’re in a place that’s reliant on good code (and good execution strategies) to exist, and the other people don’t or won’t or can’t really grasp the magnitude of what good code means to the company - leave.

mistermann 97 days ago [-]
> At the end of the day the goal is not to produce clean code. It's to make your company successful.

An even more accurate description: don't assume anything, determine what the goals of the power player employees at the company are, and follow their lead. Assumptions of doing a good job, helping the business, fulfilling the mission statement all seem like reasonable goals, but assuming you are working in a reasonable organization is not always a safe one. Sometimes, the whole thing is mostly smoke and mirrors, and someone coming along with the aim of doing a good job will become very unpopular.

If you happen to find yourself in one of these places, just imagine yourself on the set of a TV series about an IT department, say all the right things, and you might very well be able to get paid to play around with things that interest you 90% of the time while keeping up appearances with your other 10%. Be mindful of what this can do to your resume and skillset, but as long as you're making productive use of your time learning new technology, you can typically lie about what you did at your last job and most interviewers won't have a clue anyways.

laythea 97 days ago [-]
This is a very good, professional response.
Balgair 97 days ago [-]
Put another way:

"If it's just a stepping stone, then be fascinated by the shape of the stone"

-Ze Frank

jogjayr 97 days ago [-]
"Like anything in life: Do the right thing, even when you're surrounded by villains."

That's a tiring way to live life too. If you're surrounded by villains, you should try to leave and go to a place where doing the right thing is easy. If at all possible.

mkempe 97 days ago [-]
Strongly agree. Still, do keep some of your powder dry and look for opportunities to join a better team or company.

An engineer once told me he cried with joy when he saw the interface and used some subsystem I had written a year earlier (in C, for an embedded system). So, I encourage you to write such great, beautiful code that other engineers will cry with joy when they behold and maintain it.

space_fountain 97 days ago [-]
I definitely do the best I can, but as someone sort of in this position I worry that I'm becoming a worse programmer for it.

I'm junior enough that I often don't know what to do. I've never gotten really good at full unit testing for example. I really do think in situations like this my best bet is trying to find somewhere where they follow better practices.

zamber 97 days ago [-]
Imitation is the best form of flattery but you can also be proactive in your learning how to write better. Read code that's open-source and solves similar issues for a similar case in the same tech stack. Understand the architecture and conventions. Understand where the codebase has areas for improvement.

Before you learn about types of hammers and nails learn when to use which one.

The problem with more senior people is that they can lack the time and motivation to teach you so until you don't own the problem yourself pushing it to "ppl don't want to teach me :(" will not do anything.

Also, practice makes perfect and good coding practices tend to be somewhat universal.

lamby 97 days ago [-]
A friend once wrote on Reddit:

> High standards for workmanship and worker safety are luxuries, but even some people who have the benefit of access to good training and safe workplaces don't take advantage of them. You shouldn't be ashamed of striving for the highest quality work you can do — instead, be thankful that you know what to strive for, and pass on your craftsmanship to anyone who is willing to learn.

SaltyBackendGuy 97 days ago [-]
I wish I could upvote this more than once. Reminds me of one of my old Army SSG. Simply, do the right thing.
iamcasen 97 days ago [-]
That's all well and good, but what if delivering good code actually necessitates a pretty large shift in the codebase? Usually that requires buy-in from teammates because it will take substantially longer.

Almost always the answer will be no. So you're forced in a way to ship bad code.

Terr_ 97 days ago [-]
I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity."

I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE.

It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change."


SIRHAMY 97 days ago [-]
At that point, you could probably bring in Legal. Not only are these just poor coding practices, but some of these things are very serious security vulnerabilities. If you've got contracts with clients, or even if you're licensed straight to individuals, it's a good bet that you're breaching some data security/privacy rules. Legal would definitely want to know and take steps to correct.
user5994461 97 days ago [-]
This is terrible advice. Do not go to legal for this, ever. This is putting yourself and the company in a very bad position.

Fix the vulnerability if you can. Help junior developers understand common issues if you can. Then move on to the next job with better practices.

dragonwriter 97 days ago [-]
> but some of these things are very serious security vulnerabilities.

That's a very good reason to bring in your Security Officer or a similar compliance officer; its probably not a good reason to go straight from dev to Legal.

Retric 97 days ago [-]
Don't stress about code quality.

Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place.

PS: This is not giving up, it's about getting even better by becoming ever more flexible.

mike986 97 days ago [-]
this is very selfish, unless you're the only developer in your shop.

whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU

Retric 97 days ago [-]
Don't assume I am talking about personal ROI. Team ROI is critical. Seeing a feature early so we can decide if the goal needs to be changed it valuable. Clean code that's going to be deleted tomorrow is not.

The 3rd time you touch a function is often a great time to make it awesome. However, a lot of code never reaches production and maintainability is more of an issue for code that survives.

drdeadringer 97 days ago [-]
Not just your coworkers today, "future you" as well.

I've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.

Retric 97 days ago [-]
If it worked for a year without bugs, then it's not garbage.

Did it work? Can you read and understand it? Then it has value.

user5994461 97 days ago [-]
Unless it had no users or it was so much garbage that nobody reported any bug.
Retric 97 days ago [-]
That would mean it did not work.
Retric 96 days ago [-]
PS: The goal of Windows is not to create an OS the goal of Windows is to make Microsoft money.
betenoire 97 days ago [-]
There is a lot of binary discussion here that treats code as either clean or not. Of course, it's always somewhere in the middle.

Finding the right line in the sand for your current job is an art. There is ALWAYS more you can do, and being smartly-selfish is inevitable.

laythea 97 days ago [-]
I don't think the parent was talking about writing bad code. I think he/she was saying not to stress about writing good code too much. Those are different things.
ThrustVectoring 97 days ago [-]
This is why you want to do some work in the interviewing steps to see if the company you're considering has a culture of code quality and mature engineering processes. "What do you need to do to release code?" "Do you do code reviews?" "How do you set aside time for refactoring?" and so forth
akud 97 days ago [-]
It's not a tradeoff. The reason we like quality code is it saves time in the long run by being clear, easy to change, less error-prone, etc. If you expect to be employed in 6 months, you should be refactoring and putting care into the quality of your code. It's hard at first, but I'm at a point where I'm the most productive engineer and I work the least amount of hours - because my code is there to help me, not hurt me.
skookumchuck 97 days ago [-]
I've seen a lot of well-intentioned code refactoring that made the code objectively worse. Refactoring well takes a pretty seasoned programmer to do it.
ComputerGuru 98 days ago [-]
There needs to be a sense of ownership and pride. Even my side projects are written then rewritten over and over again until I’m personally satisfied with my approach and the quality of the code. If I use a hack to get something done on code no one but myself will ever see, I still leave a shame comment (//mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.)

We aren’t dealing with anything new in terms of work ethics and quality control in software development. I maintain my code quality the same way a carpenter 2,000 years ago would have cared about how well the insides of a finished product are designed, whether it exceeds its required specifications, what other carpenters would think of their work, how they would feel if a future apprentice or master saw what they created that day, and so on and so forth.

Additionally, I place a premium on “skills learned or perfected” over “bugs closed or features implemented.” If xx is better implemented via an approach I haven’t used before - well, here’s my chance to learn how to do that. Sure, it’ll delay the process. But that’s where technical debt comes from. I may only end up writing ten lines of code that took me 17 hours to figure out and understand, but if those are the right ten lines of code then whatever else I could have or would have written or accomplished in those 17 hours doesn’t matter.

When the goal is “closing JIRA issues or GitHub PRs” and the only metric is how many bugs you closed that day, code quality will suffer. But instill that sense of pride, take ownership in your work and create an environment where others are encouraged to do the same, and it’s a different matter.

ionforce 97 days ago [-]
> I place a premium

I think the problem is are you saying this as an individual or are you saying this as someone in leadership with power.

Place a premium all you want. But if you're a grunt, that opinion is going straight to dev null.

laythea 97 days ago [-]
I laughed at this :)
LrnByTeach 97 days ago [-]
carpenter 2,000 years a very good analogy with quality of code.

This is very good reward system for developers . placing a premium on “skills learned or perfected” over “bugs closed or features implemented”

> We aren’t dealing with anything new in terms of work ethics and quality control in software development. I maintain my code quality the same way a carpenter 2,000 years ago would have cared about how well the insides of a finished product are designed, whether it exceeds its required specifications, what other carpenters would think of their work, how they would feel if a future apprentice or master saw what they created that day, and so on and so forth.

> Additionally, I place a premium on “skills learned or perfected” over “bugs closed or features implemented.” If xx is better implemented via an approach I haven’t used before - well, here’s my chance to learn how to do that. Sure, it’ll delay the process. But that’s where technical debt comes from.

dep_b 98 days ago [-]
You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals.

Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smaller side effect free function you just created.

It takes a ton of time and patience but every week the kraken loses a tentacle. And once most code feels untangled you can embark on a refactor since all of the parts are movable now.

aalleavitch 98 days ago [-]
This is absolutely the situation I am in right now, and I desperately need all the guidance I can get. We’re talking thousands of lines of React components that rely regularly on manipulating global js variables, mixed with MVC 5 written in Razor delivering variables in script tags, mixed with outdated jQuery, that’s all just concat’d together with gulp and that hasn’t seen a refactor in years of changing hands with no style guide. The company started in 2004 and I swear some of this code is still floating around from the day it started. We have three sets of scss breakpoints, three or four layers of “common.scss” files that act like a piece of furniture that has been painted over dozens of time (with shit like * {padding:5px} floating around), and an unknown amount of dead code. There’s lines written back-to-back with vastly different styles (with a random distribution of semi-colons and arrow functions and etc), and major global variables named with misspellings. And while I clean this all up, I am expected to continue pushing out features and addressing serious bugs with stop-gap measures.

Please advise.

Kesty 98 days ago [-]
Welcome to code development in the real world 101.

You either go insane, give up and take up beekeeping, start your own company or finally decide to not give a shit anymore and start hacking the same way as everybody else because in the end your are not sending astronauts to Mars, and it works "most of the time" is good enough for the clients and the price and time they are willing to pay.

pavel_lishin 97 days ago [-]
> take up beekeeping

I thought the idea was to have less bugs to worry about...

jdbernard 97 days ago [-]
Yeah. On the whole, it is less. ;)
user5994461 97 days ago [-]
Real world 303.

Work for a company and project sending astronaut to Mars, then you can care and be surrounded by coworkers who care too.

jlongster 98 days ago [-]
You need to tell your manager that it's simply impossible to both clean all that up and also make progress on the project. You need to stop the erosion in order to fix it; fixing will require fundamental changes that will absolutely block progress. If aren't able to freeze the project, your cleanup progress will be constantly thwarted by new ugly hacks.

There's just no way around it. If your managers won't freeze the project until you make meaningful progress, you're going to be stuck working with this ugly code for a long time. Try to convince them that in the long-term a cleanup will pay dividends. Without their support though, you won't get anywhere.

If you're able to freeze the code for a bit, it sounds like it might just be quicker to rewrite some parts like the CSS. Don't take on the whole project at once - find pieces that can be rewritten individually, even if it's a large part like all the styling.

tmorton 97 days ago [-]
I disagree with most of this comment, but I think it's an interesting and valuable discussion.

Here's where we agree: You need to stop the erosion in order to fix it. Every developer on the project needs a shared vision of what "better" means. For example, the parent comment mentions React components that manipulate global variables. First of all, everyone agrees to stop doing that, and agrees on the alternative (use props, a redux store, whatever).

But you don't stop the world and rewrite to the new standard. Instead, you apply a strong "boy scout rule" to every code change. If a developer modifies a small component, they also need to remove the global references. If the existing component is large, the developer must extract a smaller one, and the new extracted component must meet the new standard.

This will slow your velocity - at first, by a lot. But you never stop delivering entirely. You never waste time rewriting things that you would never touch again anyway. You also learn along the way - because while "don't use globals" is pretty universal, most architectural decisions are not. You will find that the "clean new standard" changes to match your application. At the same time, everyone on the team learns about the new standard, and buys in to the new way of doing things. There isn't a "new system" with the cool kids, while the B-team strings along the old one and waits to be laid off.

Clubber 97 days ago [-]
That's what I've always done. Fix it when you see it. Eventually, you have a clean codebase.
Jach 97 days ago [-]
I've mixed feelings on this still. It leads to big code reviews, with most of the changes being less important. So I rather like the separation, spend some time just for cleanup. Maybe take notes on wins as you see them but you don't need to do them yet (or put them in the same review as another bug fix / story item).

If you're using git and can separate things out cleanly then I think fixing it as you go would work better. I yearn to use git every day again...

Clubber 97 days ago [-]
Well, I'm not talking about a major refactor (squash them when you see them). This should be an enum, this is named poorly, this variable is scoped wrong, inline sql when should be a sproc, that kinda stuff. A few lines a fix, the low hanging fruit.

Major refactors certainly need to be accounted for in a sprint(s), but keep features a priority when needed in sprints.

aalleavitch 98 days ago [-]
Unfortunately there are business reasons why freezing the code is impossible. We’re ecommerce and working on a timeline dictated by consumer behavior. So if we need a promo tomorrow it’s going live or else we’re not making budget. I kind of assume this is how we got into this state to begin with.
Kesty 98 days ago [-]
And unfortunately nothing will change because what you want to do is better in every single way, but their way of doing thing is better in the only one that actually counts: It's faster and cheaper.
aalleavitch 98 days ago [-]
My assumption is that I will never clean up this entire codebase. Rather, I’m looking for the best way to triage the situation: what are the things I can/should try to fix first?
foobarrio 97 days ago [-]
Make your problem their problem.

Make a list and organize all the things you'd want to change. Untangling balls of mud often take on the order of months to start seeing any kind of progress. You have to make sure you keep things organized over a long time otherwise you can't tell whether or not you are making progress.

If a module breaks often when seemingly unrelated things change or breaks every time someone touches it it's easy to say the module is badly written. It's often hard to say why it's bad and harder to say how to fix it. However at least you will have data and be able to defend your position that messy code in a particular module actually slowed down the addition of a new business features.

If you are using a bug tracking tool (Jira, Bugzilla etc) make a bunch of private ones for yourself. If management doesn't like all your private tasks showing up on reports then try to get a section for yourself or see if you can deploy your own "private" bug tracking instance.

Any time you encounter a problem make a bug for it even if you have no solution. If upgrading a library version a minor version causes a break make a bug for it etc. You'll start to see patterns and then you can make small but really important surgery on the code. You can have a plan for how to fix a particular module when the time arises.

For example we had a core module with some 190 downstream internal clients across some 5 different dev teams. A recent Oracle version upgrade caused problems because we would have to to coordinate everyone to update at the same time. I already had a long time standing issue that the module is poorly organized and already had a list of all the things that were wrong with it. When this issue came up I immediately stepped in and how to completely remove Oracle from the core module so that the downstream clients can each upgrade on their own time. Because I had thought about this for time I was ready to defend the proposal by showing it would take less time to do this. I was able to do a refactoring I've been wanting to do. Over time people will start to listen to you more if you are actually delivering shit on time. Otherwise, even if your complaints are correct, you will be labelled as just a whiner.

danharaj 98 days ago [-]
Write down everything you know about the codebase. Whenever you discover a surprising dependency or behavior make a note of it. This is something you can do in passing as you push features.

At some point you'll start recognizing structures in the code some of which will be small enough to surgically improve.

ozim 97 days ago [-]
How will you make sure that you are not introducing regressions in such code base? You cannot add unit tests because it is probably untestable mess. So instead of some uncertain dividends, which may or may not materialize, you introduce real risk of breaking already existing stuff.
bigjimmyk3 98 days ago [-]
For "light reading" on this subject, try _Working Effectively With Legacy Code_ by Michael Feathers. We used it to very good effect at my last company.
malingo 97 days ago [-]
Michael Feathers was on Software Engineering Radio last year:
WorkLifeBalance 97 days ago [-]
Personally I thrive in this kind of environment, it's a kind of comfortable chaos. MVC5 is positively modern compared to many of the products I've worked with which have included (within the last 5 years) VB6 winforms but mostly aspx webforms.

Understand that previous developers might not know what a DOM is have likely written ad-hoc jquery snippets, included 3 different versions of jquery-ui until they happened across the right combinations of versions to get their plugins to play and will have a mentality of "it was working".

Given that, here's some advise on how to stay sane:

1. Read and "Digest Working Effectively with Legacy Code" but accept you'll likely not be empowered to actually implement the changes.

2. Understand you'll have a grace period of ~6 months where you'll be far more empowered to make changes and get suggestions pushed through, after which you'll likely find yourself worn down by the system and more accepting of the status-quo. Leverage this time if you can.

3. Try to identify what caused the product to get to the state it is so it can be avoided for future products. If it's something you're not empowered to change such as "bad hiring policy" try to work out how you can spot that in future interviews.

4. Be pro-active in looking for bugs, particularly security flaws. Finding an IDOR which lets you get cross-account data is usually fairly straightforward in these kinds of environments. Doing so gets you noticed so you're not just another cog in the system and can provide real value. Be careful not to put others' out too much while doing this. It sounds like you only work on the front-end but even what appears to be front-end can have security implications such as template-injection.

5. Draw a line in the sand. Be entire accepting in legacy code but if someone is working on a new part of the product or is fixing a bug in legacy code be absolutely ruthless in what you'll let passed in code review. This may not do you any favours socially but a reputation for harsh code reviews isn't all bad. For one thing you'll have to do fewer code reviews.

6. Don't bite off more than you can chew. Treat it like a giant knot and don't be tempted to pull at threads unless absolutely necessary. Instead wait until given strong reasons for refactoring.

Edit: formatting, because HN doesn't do markdown.

Floegipoky 97 days ago [-]
In regards to #5, worth pointing out that some coworkers are probably just as disappointed with the current state of affairs as you. They would probably really appreciate somebody pushing them to hone their craft.

Also worth considering that some people never learned how to handle constructive criticism and will take any suggestions as personal attacks. Stay as far away from these people as possible, you aren't going to change them but their pettiness can make your life miserable, particularly if they're closer to management than you are.

geezerjay 97 days ago [-]
It should be noted that more often than not there are strong reasons besides ignorance and incompetence for a project to arrive at a certain state.

It shoud be stressed that a developer should not assume all his predecessors were wrong just because he doesn't understand why some stuff ended up being the way it is. The world is packed with developers who proud themselves of fixing things that were never broken, and in the process break stuff.

testplzignore 97 days ago [-]
> if someone is working on a new part of the product or is fixing a bug in legacy code be absolutely ruthless in what you'll let passed in code review. This may not do you any favours socially but a reputation for harsh code reviews isn't all bad.

In my experience this is the most important thing. I particularly focus on the "what the heck does this code even do" aspect - the person who is modifying the code needs to be able to explain exactly what the code does and why it is correct (don't accept "it compiles and the one unit test we have passes"). Forcing the team to understand the code will make it very difficult for them to continue adding bad code to the pile, as they won't be able to explain what they bad code does, or will realize the code is bad in the course of trying to explain it.

s73v3r_ 97 days ago [-]
It is very, very important in this situation, however, to not be outright mean. Do not let anything through that you would not be comfortable maintaining, but don't be a dick about it. All that will end up accomplishing is that you'll be blamed for things not going through, and then you'll lose your credibility as steward of the code. People will go over your head to the boss, who will just make you pass it.
ndh2 97 days ago [-]
Unfortunately 5. doesn't work if your company doesn't do any code reviews.
camgunz 97 days ago [-]
You should trust your engineering judgement, and your tech lead should listen to you when you raise these issues, and your product team should give your team engineering time to start cleaning things up. If any of this doesn't happen, get a different job.

As engineers we have a responsibility to raise concerns about bad practices and projects that have been neglected this way. Doctors raise concerns about hospitals, lawyers raise concerns about firms and enterprises, structural engineers raise concerns about buildings and infrastructure. Software engineers should do the same, resigning in protest if need be.

dep_b 97 days ago [-]
First agree on what it should actually be and document that. Make sure nobody commits anything that makes the codebase worse. Don’t refactor but clean first, and only while delivering value.
rocky1138 97 days ago [-]
Rule 1: No new bullshit hacks make it in.

Rule 2: One bullshit hack must be removed per sprint.

Over time, you'll have better software.

crdoconnor 98 days ago [-]
IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor).

The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't.

Edit: I am aware that coders have OCD impulses which can be sated with a linter, but priority #1 when fixing spaghetti code is unraveling the spaghetti, not sating your need to see }s in a place that makes you feel better.

simonpantzare 98 days ago [-]
I'd argue that there's a significant mental overhead reading code when it doesn't follow the same conventions, and that enforcing a style guide is a matter of having no broken windows. But of course there's no point trying to make shit look good.
dep_b 98 days ago [-]
A linter and code conventions are a way to make code more consistent and easier to switch between. At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. If I open a file and everything "just feels wrong" but I can't change it because enforcing my personal preferences are just my personal preferences is just making things worse that really takes some valuable energy away I could use for actually improving things. But I can get used to a coding guideline that's not 100% my preference but a well enforced and consistent one. Knowing that if I fix indenting and naming the fix will not enrage someone else.
dasmoth 98 days ago [-]
At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing.

I suspect this is the big point of disagreement between lint-advocates and many of those who are dubious. I generally don’t see big wins from collectivising code, and on the who prefer to treat people I’m working with as individuals who can be interacted with 1:1 vs an amorphous “the team” writing “the codebase”.

dep_b 97 days ago [-]
Usually there’s a style that’s mandated by large authorities like C# formatting is mandated by Microsoft and JetBrains. Copying their style gets you there for 80%. The rest is whatever you agree on and usually not something that bothers me.

If you’re the guy that thinks having a 300 line function in an 8000 line class is just an individual way of expressing yourself you’ll have to fight me.

If you think real tabs is better than 4 spaces I shrug and let you have it your way.

dasmoth 97 days ago [-]
The fact that you’ve named an IDE vendor rather emphasises that there is a substantial gray area. By no means everyone wants to use an IDE (let alone that specific one...)
dep_b 97 days ago [-]
True. But for Objective-C I often used the NY Times style guide. Just whatever the one is that is the most complete and most easy to maintain really. But I notice with C# that if I copy-paste reasonably fresh code from Stack Overflow to VS + RS I sometimes get zero warnings because the other programmer uses exactly the same toolchain and style. Same goes for Python PEP8 in PyCharm. Personally I like the idea of having a strong similarity in code style within an ecosystem, especially when dealing with libraries that more or less follow the same conventions as the code that I wrote myself.
lloeki 98 days ago [-]
We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier to seeing patterns and enabling refactoring.
crdoconnor 98 days ago [-]
IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves".

  lint [cosmetic | medium | serious]
- you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you might plausibly say "I'm not unhappy that broke the build because it could have indicated a bug".

  lint medium --against=branch
- the linting tool should be able to intelligently compare against a baseline branch and only warn you about issues on code you have actually touched.

I do not agree that the holistic effect of having a code base "normalized" is "through the roof". I think the cost is relatively high while the benefits are relatively low. Right now at work if I run a linter against my code there are about 10,000 "issues" - the top 50 of which are completely cosmetic and I'd be remiss to invest time in fixing them.

I'm not opposed to linters on principle and I do use them, I just think that there's almost always bigger fish to fry.

rhizome 97 days ago [-]
In this case, rubocop is indeed configurable:
icebraining 97 days ago [-]
pylint has different levels you can select (convention, refactor, warning, error), not sure if it's a common feature.

For the second, see git-lint:

yesbabyyes 97 days ago [-]
Regarding the linting levels, for eslint you can configure any rules. Just use different .eslintrc and you should be all set.

Regarding the changeset, I think you could roll that pretty easily with something like `git diff --name-only | xargs eslint`.

TheCoelacanth 97 days ago [-]
A lot of cosmetic rules can be fixed automatically (e.g. `eslint --fix`). In that case the cost of having them on is near-zero, so even though the benefits are pretty mild the ROI is still positive.
dasmoth 97 days ago [-]
Yep, a tool that did all of this might be enough to convince me.
bunderbunder 98 days ago [-]
I agree, linting doesn't pick up much. But, at places I've worked where the codebase was kept linted, the humans did a better job of catching bugs in code review.

My guess is that, when you have a cosmetically messy code base, people start to develop a lower standard for what counts a understanding the code they're reading. Probably as a self-preservation mechanism. There's only so much time in a day.

ryanianian 98 days ago [-]
Also: if your coworkers care enough about quality to add and maintain a linter, they're the kind of coworkers that care to do good code-reviews and maintain a high quality bar.
jerf 98 days ago [-]
"IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor)."

What language are you using? Dynamic languages are fairly difficult to meaningfully lint because it's hard enough just to analyze a function for problems, let alone extend past that. Static languages are easier to write non-trivial linters for, because there's more information just sitting there in the source, waiting for something to grab it.

But even for dynamic languages, linters can still do things like enforce documentation standards, code testing/coverage standards, and some other basics that may sound trivial, but still add up to very useful things.

spc476 97 days ago [-]
I find luacheck (a linter for Lua) invaluable for picking up typos, unused variables, variables shadowing other variables and unintentional global use (since Lua defaults to global by default). The types of checks seems mostly reasonable to me [1][2].


[2] I'm not entirely happy with the formatting issues, but they can be easily disabled.

Edit: hit submit by mistake.

troels 98 days ago [-]
Depends. Some programmers have absolutely no hygiene wrt formatting. You'd want that sorted for readability.

But the bigger point is that you reduce merge conflicts since you won't have all sorts of unrelated formatting changes mixed in with the real changes.

ionforce 97 days ago [-]
> Some programmers have absolutely no hygiene wrt formatting.

I don't know how these kinds of people live with themselves or are tolerated by others. I hate it.

sjellis 97 days ago [-]
"The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't."

I think that ideally, linting and especially formatting help quality by taking the trivial issues off the table. If your code is currently "clean", and the tools reformat or flag the code that you just wrote, then hopefully those issues will never be committed into the repository, so human code review can be about substantive points.

mathgeek 98 days ago [-]
Most linters allow you to disable whitespace linting. Good tools allow you to learn to use them better.
infectoid 97 days ago [-]
Great advice here. Agree on a process. Do it slowly.

I work with a lot of legacy code and have felt overwhelmed at times by all the different coding styles that have been used through the code base and not know when to refactor or simply clean up.

Over the last year or two I've been using a linter to help me with all this. Basically any code I touch gets cleaned to the point the linter isn't complaining. This is usually a fairly quick and fun process and I've actually learned a lot along the way.

I would refactor as soon as too many things were touching and the code started to have a smell about it even though the linter wasn't complaining.

It has made maintaining legacy code more fun (almost like a game) and given me some better practices when moving into new code.

crdoconnor 98 days ago [-]
Some things I've learned about code quality in organizations where the quality is terrible:

1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer.

2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? They can't tell. They will usually default to seniority (meaning how long a developer has been with an org, not how good they are).

3. These organizations reward fires that are put out. They do not reward fires that were prevented from happening in the first place. Those "senior" developers will frequently be rewarded for putting out fires they caused.

4. If you do a lot of work that prevents fires and that means you weren't working on features or bugfixes, you are going to get punished, not rewarded because to the people above you it looked like you were doing nothing.

5. If you're going to do this kind of work, you need serious intrinsic motivation.

ConceptJunkie 97 days ago [-]
I would add that management will gladly save an hour now, even if it costs 10 hours down the road.

I'm getting really tired of the message from management of "Here's what we should do, here's why we should do it, and here's why we won't."

In other words, they will periodically acknowledge that there are systemic and cultural problems that seriously need to be addressed, but consistently fail to address them.

maxxxxx 98 days ago [-]
In general I agree with your points. But you seem to have some gripes with "senior" engineers. I think if you left that out your points would be better. In the end it comes down to management not understanding the work and rewarding unproductive behavior. This has nothing to do with "junior" or "senior."
l_t 97 days ago [-]
While I haven't personally worked at such a company, I've observed some "toxic" workplaces and found that typically it is, in fact, the senior staff who are the biggest part of the problem.

Only certain types of people achieve seniority in a toxic organization, and they are typically those who (deliberately or incidentally) benefit from the culture that everyone else hates. They build a clique and try to build influence while the new hires -- who actually care about doing things well -- turn over every 3 months.

This is all anecdotal, of course, but I do think that in an engineering-hostile organization, the senior staff should typically take the brunt of the blame (just as in a successful organization they would take the lion's share of the credit).

maxxxxx 97 days ago [-]
I guess that makes sense. If the org is dysfunctional the best people at some point will have left leaving the not so good people.

But I think that change often has to come from management. Even if you are senior you often can't do much about stupid management other than leave.

crdoconnor 97 days ago [-]
It's not seniority per se (I count as senior), it's people with long tenure. If, as a developer, you've had a long tenure in an organization with bad code that's usually a bad sign.
W0lf 98 days ago [-]
Yes, you summed up perfectly what I've been experiencing in my professional career for quite some time now.
foobarrio 97 days ago [-]
I like this list. What I have found about point #4 is that even teams that try to actually measure performance in a meaningful way will miss things.

If the quality of the software is slowing down feature releases, causing fires but is not being measured, you can make some headway with presenting ways to measure code quality so that your work shows up on their radar. This is difficult with such a subjective word as "quality" but tracking number of fires of time would be a good way to show that the way you develop is better than other people.

The other thing that companies miss are employees that help other employees in a mentoring sort of way. These people essentially cast a buff on everyone they work with. These buffs can be in the form of better tools, improved workflows, recommending reading material, new technologies etc. Unfortunately it seems this is up to that person's superior to recognize their value and fend for that person to upper management. I feel like it's easy for me to identify peers that cast buffs but not sure how easy it would be for a manager to identify such characters.

carlmr 98 days ago [-]
So what is the prescription to find a company that doesn't check these 5 boxes?
crdoconnor 98 days ago [-]
In general the companies that don't both A) pay better and B) are located in tech hubs / do remote work. So, go for more money, prefer remote or in a tech hub.

You can also ask during interview about the coding experience of the manager you will report to. Usually they are up front about it. If you turn them down, do us all a favour and let the company know that was why (more coding managers and fewer MBAs please!).

I'm not gonna lie, it's not going to be possible for everybody to avoid this kind of company, especially in the more backwater places. I left Singapore because I basically found one company that didn't obviously follow that pattern. They frustrated me too for other reasons so I didn't take their offer.

I think that this is one of the most underrated reasons for the formation of technology hubs and one reason why Singapore, in spite of really trying to become a "silicon valley of asia" (VC money: check, money pumped into education: check, huge startup grants: check) just won't, and will bleed rather than attract talent.

petagonoral 98 days ago [-]
> You can also ask during interview about the coding experience of the manager you will report to.

Yes, for tech leadership. No for people management.

Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.

crdoconnor 97 days ago [-]
>Yes, for tech leadership. No for people management.

A good tech leader can handle people management too. A good "people management" leader can't handle tech. You want both.

>Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.

Good tech managers will trust the judgement of their team and know when to give them agency and when to overrule them (there are sometimes legit reasons to do it).

petagonoral 97 days ago [-]
Not in my experience.

Happy productive teams are teams which have a tech lead making tech choices (& involving team to some extent), with the people management side taken care of by a (dedicated) people manager who can cut across multiple teams ( & also taking care of the people management of the tech lead)

pjmlp 98 days ago [-]
Start your own.
ashelmire 97 days ago [-], this is my organization to a T.

Needless to say, it's time for a move upward and outward.

ataturk 98 days ago [-]
A big problem in the IT world today is that #1 is no longer the case--it is marketing departments that are driving a lot of software development and they don't care about standards, code quality, tests, anything. It's a bad culture change.
pgsandstrom 98 days ago [-]
> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old.

Is it just me, or is less that four years not "really old"?

Fradow 98 days ago [-]
There is a real difference between a properly maintained, up-to-date project that happened to be started four years ago, and a project that was started four years ago, has never seen any dependencies update (not even security fixes), and is dirty hack over dirty hack.

By the tone of the article, the author is clearly talking about the second kind.

user5994461 97 days ago [-]
There was barely anything new outside of web development.

Java code, C++ and python from 2014 could be untouched and still working fine.

jacquesm 98 days ago [-]
The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another.

Software does not age well when it isn't constructed properly.

philbarr 98 days ago [-]
My favourite quote from, "Working Effectively With Legacy Code" by Michael Feathers:

"They're writing legacy code, man!"

jacquesm 98 days ago [-]
I've - unfortunately - seen a case like that a couple of weeks ago. Very sad, moreso because they did not realize they were simply replaying the past. With all the best intentions of course.
justherefortart 98 days ago [-]
My company is hiring a company for the 5th or so time to outsource IT to this new wonder app that will replace us. It's being built in Cold Fusion. Lmfao, 22 years old out of the gate.

So far they're about 2-3m in trying to replace us. Never gets far. Worst managed company I've ever seen. And as a consultant/contractor for 25+ years I've seen a lot of horribly run companies.

troels 98 days ago [-]
CF still exists?
justherefortart 98 days ago [-]
Apparently. I just started laughing when I heard about it. I'm going to pitch an ASP (classic) project next!
troels 98 days ago [-]
I don't know if you're joking or not about the ASP classic.
justherefortart 98 days ago [-]
I'm joking. I would not start a new project in Classic ASP in 2003, much less 2018.

I did like it back in the day though and it was still a better choice than .Net 1.0. .Net 1.1 was okay, by 2.0 it was pretty decent. 4.0 beyond is fantastic IMO. I'm a bit of an MS fan though. I like their tools.

troels 97 days ago [-]
That's a relief. :)
jimmy1 98 days ago [-]
In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time.

Downvotes are usually reserved for when a comment is low quality or not relevant to the conversation at hand. Could you please explain if my comment fit into these categories for my own learning? Thank you.

eitland 98 days ago [-]
Like it or not but legacy has taken a new meaning in software.

I think it is Michael Feathers who defines it as code without tests in "Working Effectively With Legacy Code".

(That said, I didn't downvote you and I'm also tired of the abuse of the downvote button. I think in your case they downvoted because it seemed like unproductive nitpicking.)

jimmy1 97 days ago [-]
Oh I know, that's why I am rebelling! I think words mean very specific things. I know it may seem like unproductive nitpicking, but in my experience the hundreds of discussions I have witnessed and been a part of myself in discussing legacy systems, bringing the pejorative version of the term to the table usually hinders the discussion more than anything, and it is this attitude that greatly contributes to the "software is eating the world" problem we soon to experience with everyone recreating the same library every day instead of reusing existing, proven solutions -- talk about unproductive!

"Back in my day", legacy systems were admired! I mean, heck, they were still there because some team(s) were using them every day, more often than not, they were there because they made money.

As one famous software engineer once said, "'Legacy code' often differs from its suggested alternative by actually working and scaling."

NASA was reusing code written from the 70's all the way up to 2011! Surely there is something in this wonderful land of legacy code that is worth saving? Or how about our operating systems? Full of wonderfully working legacy software that might just need a touch of love, rather than the usual thrashing of "how stupid those other devs were" and a total rewrite, which is what usually happens sadly.

In any case, I think another poster may have touched on it, I think we as engineers should try to refrain from flippantly labeling anything that is essentially "old" (where "old" might be 6 months, 2 years, or 10 depending on the organization) as the pejorative form of "legacy software", and just call it what it is -- bad software, some of which may also be legacy to your organization. But the conflation of the two terms is not helpful and adding to the confusion.

jacquesm 97 days ago [-]
I've worked on old but very well maintained code that could easily go another two decades or more. Probably the original writers have long departed this world. But what they put together was put together with either incredible forethought or impeccably kept up-to-date. It was hard to tell which because this stuff was built before the age of version control, which gives you a bit of an idea how old it was. I would consider that 'mature' code, but not necessarily legacy.

Legacy code to me is code that has become hard or even impossible to maintain. Code that people avoid working on, not because it works, but because they are afraid of it.

Sure there are still lessons to be learned from such code, and you will learn those lessons the hard way if you have the temerity to mess with it. But every now and then someone is tasked with fixing a bug or adding a feature that can no longer be avoided and the send-offs are comparable to talking for the last time to people that are about to descend into a mine or something to that effect. Everybody knows there is a good chance we won't be seeing them again for the near future, if the axe of demotivation doesn't cull them from our ranks.

jacquesm 98 days ago [-]
I like that definition. Maybe another one: code that nobody knows intimately.
Clubber 97 days ago [-]
I've always known it as software that exists and is actively being rewritten, so a mainframe system would be the legacy system while writing a new Windows application to replace it.
bethly 97 days ago [-]
Anyone can pitch a tent: building a house is harder.

Given that we need a lot of housing and we don't have many home builders, there are a lot of tents floating around this industry.

dwc 98 days ago [-]
Of course it's not really old. Though in my experience age has only a loose correlation to overall code quality. Some really old programs were well architected to start and have been carefully maintained. OTOH, I've worked with devs who are one-person technical debt factories, and allowed to work on relatively young and sparse applications will quickly make it an unmaintainable monstrosity.
stochastic_monk 98 days ago [-]
My lab has a tool which has been actively maintained for 10 years and has a full-time employee supporting it and a related follow-up from 3 years later.

It takes a lot of effort to keep cross-platform support while continuously improving it. Granted, not every project deserves that kind of effort, but I respect the effort it takes to keep software up-to-date.

sesutton 98 days ago [-]
I suppose it is for webdev. I regularly work on C code that's nearly as old as I am.
_asummers 98 days ago [-]
As an Elixir dev, popping open old Erlang code bases is always an interesting experience. Some of those haven't even been touched in the last 4 years!
shadowmint 98 days ago [-]
Funny how no one has any meaningful advice, just some snark about those dang young developers. Get off my lawn!

That line wasn't the important part of this post. This one was:

> You should also have a global self-development plan. If you can’t put it into practice under the scope of the project, you should spend your free time on it.

Damn straight.

If you work somewhere with tight deadlines and rubbish code quality, and you're just sucking it up and writing rubbish code, you're part of the problem.

You should always have a plan about how to become a better more effective developer where ever you end up working. Sometimes that means plan to spend 10 minutes a day talking to your project manager. Maybe review code the last 1/2 hour of the day. Maybe make some internal tools to help automate your job.

Don't just sit there and be miserable; if your job/company sucks and you can't find a way to change it, at the very least make it a stepping stone to something better.

Some idle advice from my experiences working in places which sucked:

- If you write code, it should be good code. Even if other code is bad, that's no excuse to stop caring.

- ...but, you dont need to refactor that. Just do what you have to do, and make it as good as it can be under the circumstances. Don't break other things when you make things cleaner and better; that makes PMs think that 'good code' = 'break features'. Disaster.

- If you ship rubbish to 'come back and fix later', you'll never come back and fix it.

- Don't just comment out code and replace it a quick fix. Don't [Ignore] failing tests. If code is going away, take responsibility of actually delete it.

- Don't leave 'TODOs' in your code; either do it, or don't. No one is ever going come back and do your TODO. Not even you. That's what issue trackers are for.

- Some developers don't like running with 'trainer wheels' or 'guard rails' as they refer to unit tests. Ignore these people. Always write tests. The worse the place you work is, the more desperately you need those tests.

- Project managers (unless utterly incompetent) don't care about deliverables per se; they care about managing expectations. Estimate. Review your estimates. Try to deliver on your estimates.

- Don't work overtime unless it'll actually make a tangible difference for a specific deadline. :)

ndh2 97 days ago [-]
This is very good advice.

I would change the last point to: Don't work overtime unless you, personally, get something out of it. That something might be not getting fired. But if it doesn't get you anything... Don't do it.

pjc50 98 days ago [-]
Hah! The code I'm working on at the moment is full of banners saying

// Copyright (C) 1991 - 1999 Rational Software Corporation

I think it actually originated in 2002 and those are junk left over from the use of Rational Rose code generation. Revision history only goes back to 2007.

vorg 97 days ago [-]
> Revision history only goes back to 2007

Perhaps a former programmer deleted the revision history when they were about to move into a management role at your organization. I once stumbled upon a manager's name in the history of a 1970's Cobol program which had a goto statement every 5 lines, and it usually took half a day to make a simple change. All of the other similar-looking programs had had their history purged. When I showed the history notation to the manager, the look on his face wasn't nostalgia but fear.

sametmax 98 days ago [-]
Not old. The author is probably young. Or a js dev. Or both.
dentemple 98 days ago [-]
The author clearly explained his background in the article.
fodoj 98 days ago [-]
it's she :)
s73v3r_ 97 days ago [-]
How software is constructed has a huge impact on how well it ages. It can age like a Tolkien elf, or it can age like a fruit fly.
user5994461 97 days ago [-]
What the software is constructed has a huge impact on how well it ages. If it's javascript...
dspillett 98 days ago [-]
That is barely out of adolescence. Part of my day job is shepherding a large legacy web application into final retirement. 18 years and still trundling on, longer if you count the desktop applications that came before in the product line. Still getting new development time allocated to it too, most recently implementing improvements to help the clients comply fully with GDPR. Traced a problem in production back to a bug introduced 13 years ago just the other day...
bethly 97 days ago [-]
I worked on code that had been in active development for sixteen years, but it only got to be sixteen-year-old code because it was reasonably well-written and maintained. Code quality and developer skill is what lets software become older than four years old without collapsing under its own weight.
hiccuphippo 98 days ago [-]
That's like 20 years in JavaScript years.
yoodenvranx 98 days ago [-]
> Is it just me, or is less that four years not "really old"?

In the JS world 4 years is very old bu in the C/C++ world 4 years are still quite fresh.

Terr_ 97 days ago [-]
That seems pretty fresh to me, but I may just be jaded: I'm working with a mission-critical PHP project with portions -- including fossilized third-party libraries -- fossilized since 2009.
bbarn 98 days ago [-]
It is for the author who got his first paycheck last year.
JoeAltmaier 98 days ago [-]
My sister (contracting to a large global tire company) texted me yesterday, that she'd had to modify a module that was 30 years old!
98 days ago [-]
chii 98 days ago [-]
the javascript mentality!

software isn't old until it breaks 10 yrs!

oblio 98 days ago [-]
Debatable. Just as people, some software ages badly. Heck, sometimes it's just born old :-)
kabes 98 days ago [-]
It's just that the javascript language, frameworks and ecosystems have seen massive changes over the last couple of years. C for example hasn't seen this change. So yeah, C code from 5 years ago would look the same if written today, while javascript of just 2 year old might seem outdated.
tboyd47 98 days ago [-]
> Code review at the end of the task.

This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it.

In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or she may decline your Pull Request, request a long list of changes, or just wait ten years to give any response at all.

In a business setting with hourly pay, deadlines, and co-workers chosen for you, not by you, it makes less sense. People tend to wait until the last minute to give or request feedback which leads to a lot of thrown-away work. Unfortunately, willingness to throw away work becomes a mark of pride at some places. Maybe enterprise projects need some kind of "managed push" system instead of a "pull request" system.

Edit: "Unfortunately, willingness to throw away work becomes a mark of pride at some places." to elaborate, the thing that makes this unfortunate is that the person assumes that throwing away work is necessary for code quality to stay high. By requesting feedback at intervals (which is what the author of the article recommended), you can avoid throwing away work without sacrificing quality.

hawski 98 days ago [-]
What I don't like in "commercial" code reviews is that most reported issues are there just to fill space. It's busy work. There is this formal comment system. So instead of fixing this typo in a code comment directly reviewer writes a comment. Code style issues that arise, because of absence of a tool like go-fmt also warrant a comment. That's sad.

There are meaningful comments, but usually people have to fill their review quota.

Lowest hanging fruit should be just an in-place edit that would be automatically retested and that a reviewee can easily take as a patch and check himself. Instead of the back and forth bullshit.

It's a bit funny that placing a red herring comment that anyone can safely comment on makes the workflow faster. It's like this story about an artist who would place something ridiculous so when the time comes the CEO would just say: "It's good, just remove the thing".

dionidium 98 days ago [-]
Part of this process, especially for new team members or junior devs, is to signal that, yes, we take typos (and formatting, and proper grammar, and the style guide, etc) seriously. I could fix this myself, but I shouldn't need to. We all make mistakes, but too many "small" mistakes is an indication of sloppiness. Is this actually a mistake? Or were you just being lazy?
somethingsimple 97 days ago [-]
Agreed. In my team I am known for being extremely meticulous about this, and some people don’t like it. If I see one or two typos or spacing issues, I understand that’s an honest mistake. But if I see typos, spacing issues, bad indentation, bad naming, etc. all over your diff, I can’t help but think you’re sloppy. If you don’t care about the little things like properly formatted code, I have a hard time believing you care about the big things like error checking and proper test coverage.
Clubber 97 days ago [-]
A code formatter will save you tons and tons of man hours.
gboudrias 98 days ago [-]
Good comment. The thing to remove in the story is a duck:
boomlinde 97 days ago [-]
On the other hand, pointless bikeshedding quickly gets mutually tiresome in a setting where every line of code is reviewed in small increments. I also like to address these tiny inconsequential hangups politely when I disagree that they're important. Let's say some guy suggests changing "name" to "someNeedlesslyDescriptiveName" and I'll point out that it's already clear what it is because it's the only variable in the needlesslyDescriptive function.
epicide 98 days ago [-]
In business settings, I've seen plenty of pull requests "go stale". Usually, they come about from a) the person not updating their code based on reviews, b) the reviewers not reviewing in a timely manner, or c) the change is no longer necessary / a priority.

Usually, it is some combination of a and b. All cases are an indication of a deeper problem. None can be fixed by calling your "pull request" a "managed push" nor by giving people unrestricted access to pushing code. It's typically either a problem with communication or priorities/expectations.

pjc50 98 days ago [-]
> willingness to throw away work becomes a mark of pride at some places

Is this a typo for "willingness"?

Code review is important not just for preventing junk from entering the codebase but for ensuring that someone else has seen the thing and has some idea of how it works. I agree that "pull request" is the wrong terminology for a commercial environment.

tboyd47 98 days ago [-]
Understood. It's just that the PR model only encourages that code review to happen at the very end of the process, when the submitter may have been polishing their work, testing it, and refining it for several days. It would be more efficient for it to occur periodically throughout development, rather than at the very end.
house9-2 98 days ago [-]
I usually create a PR after the first commit and mark the PR as a WIP, then it is available for review throughout the development process. YMMV
boomlinde 97 days ago [-]
I don't necessarily see code reviews as the problem here. I think it's a very important aspect of development that unfortunately seems first in line to get cut back when other parts of the organization fail, when for the sake of quality I believe that the organization should be designed to always accommodate it.

For example, you mention waiting until the last minute and throwing away work. If this is such a big deal, maybe the units of work are too big or too loosely defined. Loosely defined as in "eh, we never needed this in the first place" or big as in "sorry about that but your 2000 LOC commit just isn't the right approach". Maybe github style reviews/pull requests are also not the best way to go about it. IMO the github style is pretty weird and shouldn't be conflated with reviewing in general.

At my current workplace, we use gerrit to review every commit. The only way that they'll ever get to master or a shared development branch is if they get a +2 vote. Maybe this is closer to a "managed push"? It's not rare that someone finds an issue, and when that happens it's very rare that it means scrapping the entire patch, and when that happens, it's usually a very small patch for a problem/feature that ended up being fixed elsewhere, so I definitely don't think it's a waste of time. Instead I am grateful that many of the patches didn't enter the codebase in their initial state.

tootie 98 days ago [-]
Tech lead is dictator. You should have a tech lead who is at least 50% hands-on coding and is enforcing the code review system and participating in as many as possible.
tboyd47 98 days ago [-]
This is an option, except for the fact that the tech lead is beholden to the same timelines and pressures from management as everyone else.
xstartup 98 days ago [-]
What do you mean by throw away? The submitter can always make the requested changes. And if the pull requests are not even relevant then it's entirely a different issue.
tboyd47 98 days ago [-]
Meaning the submitter just spent one week writing code that will have to be written over again. If they had requested feedback informally before the PR, they would have written the code correctly the first time.
Bjartr 97 days ago [-]
Having a PR workflow in place doesn't (or at least shouldn't) stop that person from seeking out that informal feedback earlier. To me it seems like what you're really looking for is pair programming, not pre-completion reviews.
Clubber 97 days ago [-]
There is a dev design/plan time that could be utilized to solve that.
flynnieous 97 days ago [-]
Or you can do pair and/or mob programming, where the review happens as the code is created. This eliminates the feedback loop and the creation of throwaway code.
house9-2 97 days ago [-]
Even when I pair program it is nice to have someone else review the code before merging. Or at a minimum do a 'self' code review after the work is complete, once you have pulled your head out of the weeds things might look different.
97 days ago [-]
detaro 98 days ago [-]
> Maybe enterprise projects need some kind of "managed push" system instead of a "pull request" system.

What would you do different in "managed push"?

tboyd47 98 days ago [-]
Not sure? Maybe letting developers push directly to master, with an automated test run at each commit and a project manager or tech lead in charge of tagging and deploying releases?
zAy0LfpBZLC8mAC 98 days ago [-]
> I think it's a result of an open source tool (GitHub) bringing bits of culture along with it.

Erm ... GitHub is entirely proprietary!?

frobozz 98 days ago [-]
I imagine the meaning is 'tool for doing open source', rather than 'tool that is open source'.
zAy0LfpBZLC8mAC 98 days ago [-]
Which still doesn't really make sense?! Plenty of open source development happens outside of github, and plenty of proprietary software development does use github ... so if that is what you mean, you could essentially say that about any software that happens to be used by some developers for the development of open source software!?
navium 98 days ago [-]
Quality means doing it right when no one is looking. - Henry Ford
marmaduke 98 days ago [-]
A clever quote saves us from having to think!

(paraphrased from some original quote I can't remember)

jacquesm 98 days ago [-]
Yes, but in this case someone else did the thinking for you and it is actually pretty accurate. If the only time you care about quality is when you are being checked, audited or supervised then it will not work.

Quality needs to be infused all across the board and needs to be reinforced from the management downwards throughout the whole organization, not just in the quality control department.

So Ford was definitely on to something and beat mr. Demming by a couple of decades on that particular insight. It's no surprise that both of them had a lot of these insights in the automotive industry to begin with, where warranties can very rapidly eat up the profit margin on the sale.

marmaduke 97 days ago [-]
isn’t this like saying quality code is code that is correct without unit tests? They seem unrelated
flynnieous 97 days ago [-]
They are related in that quality code is code that is both correct now and can easily be made correct when things change--and things always change. Unit tests are what enable correctness in the future.
navium 97 days ago [-]
Or more like, you write unit tests even if no one asked you to.
trevyn 97 days ago [-]
I’ve often wondered about a twisted form of asynchronous “pair” programming: One person codes quickly, creating mediocre code that achieves the goals, the other person cleans the code up and modularizes it.

I’m drawn to this because they are two different mindsets that achieve somewhat conflicting goals, and the tasks can be separated with minimal communication overhead.


gurkendoktor 97 days ago [-]
I just left a project after I was unable to make peace with being the cleanup guy for an endless, never-improving stream of mediocre code. I am convinced that it's faster to write solid code in the first place.

Once there are two or more interacting layers of code, it gets really hard for the refactoring to catch up. If you fix a bug in a basic layer, the leaves of the codebase break. If you fix a bug in the leaves, you never get to refactor the core. If you want to stop the world and refactor everything at once, you get in the way of your quicker counterpart.

Or think of a multithreaded codebase without any synchronization. It definitely works well enough for demoing an "almost finished" product, but cleaning it up requires a lot of time and can introduce temporary regressions (deadlocks) that are worse than the bugs that the cleanup is supposed to solve (very spurious data corruption). It's a bit like the bullshit asymmetry:

Ruby on Rails (from the OP) makes it easy to build many kinds of maintenance deathtraps.

alextheparrot 97 days ago [-]
I see this often in a slightly different context - people who write libraries well and people who write application code well. One tends to be generalized, focused on end-user ease of use, while the other is first and foremost attempting to achieve business goals with the available tools.
hinkley 97 days ago [-]
Eventually you feel like a janitor or a babysitter.

The problem is that the guy making the mess gets credit for things and the guy cleaning it up keeps bad things from happening because of him. If your boss is not just the right type then you will become the bus tribute.

JoeAltmaier 97 days ago [-]
I worked like that with a colleague of a decade in a startup environment - we produced tens of thousands of lines of embedded code in a year. It can work with a close understanding between the two people.
hindsightbias 97 days ago [-]
There used to be a time where every new coder spent a couple of years learning/maintaining their elders' code - fixing bugs, porting, optimizing, learning about how the environment(s) integrated. The concept of journeyman in sw was a thing, and mgmt/team expectations from the youts was appropriately gated.

Now it's different (outside of HW orgs), but as I look out a decade or so, I'd rather have a part-time retirement job "cleaning up" interesting projects than travel/consulting.

pavel_lishin 97 days ago [-]
I've done this very frequently on pet projects - except I'm both people. There are projects I have where I'd grab a drink, and bang something out for a few hours in the evening that works - and then, in the cold, sober light of day make sure the underlying ideas are still sound and refactor it to make it more readable.
97 days ago [-]
97 days ago [-]
taeric 97 days ago [-]
The largest burden to raising code quality I have ever seen is the conflicting burden of maintaining product quality.

That is to say, many of the loudest proponents of code quality are the first to completely disregard the customer quality points in the product.

Yes, there are fun meta arguments about how higher quality code can let you deliver faster. Nobody is going to wait for you to get to that point, though. You have actual users and customers today. Their problem is not the code's intrinsic quality. Instead, they are trying to use the product. If you can't tie their concerns to visible metrics that you can move more effectively than someone else, then you are likely just yelling at your peers. Not helping your customers.

And please, do not make the mistake of thinking you can push massive changes without breaking things. You will cause regressions. Period. If the changes are truly needed, you will make up for them with more rapid progress afterwards. Don't punish your users, but don't lie to them either. Respond and get so that you can measure your impact before they contact you about it. Reach out, apologize and make right.

bethly 97 days ago [-]
I've had business people tell me I should stop writing tests so I could go faster, even when I'm producing significantly more features than the developers around me who don't write tests. Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there.

I think we just need to stop telling people that code without tests is an option. It is an integral part of being a software developer, not a nice-to-have afterthought.

D-Coder 97 days ago [-]
"I've had business people tell me I should stop writing tests so I could go faster"

Maybe tell them that double-entry bookkeeping doubles their workload and they could go faster with single-entry bookkeeping.

sjellis 97 days ago [-]
"Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there."

This is the problem. Testing is not easy, and many developers simply aren't very proficient at it. Worse, we often don't recognise that it is a separate but important skill.

ryanmarsh 97 days ago [-]
I am a Dev Coach. This means companies hire me to pair program with their developers and help them focus on "technical excellence" which is manager speak for "code quality".

Here's what I've found:

- Most companies don't actually care about code quality. This is especially true for the ones that hire me. The managers that bring me in would much rather play-act than make the systemic changes required for their teams to operate with improving quality.

- There are systemic challenges to code quality in these environments. Namely hiring practices, performance evaluation, and priorities (budget/timeline). Obvious.

- Nobody can explain the benefit of code quality in terms persuasively enough to managers that they will accept the cost. I've never seen it done. It must come from somewhere else. This is why companies with more technical people in positions of leadership tend to have this problem less IME. Frankly I think this is why we use words like "technical debt" either that or it's a tautology. There's an irrational lack of discipline in this area akin to credit card debt.

- Furthermore, software itself does not matter to these companies.

That last one is the most important and it is not meant to be normative. I'm not saying software is not of actual importance. I'm saying it is not treated in the company with any importance. Software development is viewed as a necessary evil, not as an opportunity for competitive advantage.

The difference between my clients who view software as a necessary evil vs. a competitive advantage cannot be understated. It is immense. Often these companies with different perspectives are competitors in the same industry! You can guess which ones are growing happily and which ones are struggling to cope with changes to their business.

There are companies where the ratio of "business" people to IT is 1:3 and they balk when you tell them they're essentially a software company.

"No, we're a mortgage company."

Ok how's that working out?

What I've decided is to start doing a better assessment up front as to the actual priorities and perspective within these companies when choosing a client. There are companies where the light bulb is coming on and it can be a blast to work with them. In the current climate I would advise everyone to just flat out avoid companies that don't see themselves as tech companies. Work for companies that see themselves as tech companies or are seriously trying to change that perception internally. You can find companies like this in all industries. You might be surprised.

user5994461 97 days ago [-]
Give some names. That will tip out what stocks to buy long term and what not.

I personally found that calling oneself a tech company is not a good predictor for good practices. Everything call themselves a tech company nowadays.

You should certainly assess what kind of clients you're facing to adjust your recommendations. However, I don't think that the work environment matters as a short term consultant, whoever pays on time and has the biggest pocket is a good client.

leibnizwasright 98 days ago [-]
In many companies I worked that were like this, other developers also wanted to fix these problems. So, talking with them is also a good start I would say, if you get get one more colleague to work kind of right from beginning is a nice start too. Normally, QAs and test automation engineers will be all for improve the situation. Being a bit more vocal on these problems, but it is important to choose what should be the 1st problem to be tackled.
oldandtired 98 days ago [-]
Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on.

If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documented. Do this for your own sanity.

Don't be afraid to rebuild something if that will get you out of a bind. It will be for your own sanity to do so.

The pragmatics of cleaning up code is for your own sanity, unless you intend to leave in the near future. In that situation, it will be someone else's problem. But remember that in your next job, you'll become the someone else.

ConceptJunkie 97 days ago [-]
I absolutely follow these principles, and I often joke that I do everything I can to idiot-proof my code because the next idiot who comes around is usually me.

But unless you get support for this from middle and upper management, you're fighting a losing battle. You can't fix the world from behind the scenes. I know, I've been trying for many years.

My immediate managers have always been supportive of this attitude, but since everyone above them is concerned only with "How fast can we ship this?", and has the attitude, "We care about code quality, unless that means we have to dedicate resources to it." and "We will gladly spent 10 units of next month's or next year's resources to save 1 unit of resources for this week's release."

I understand the pressures of business needs, and sometimes you really do need to ship ASAP and sacrifice features or the insurance of quality of a well-defined piece of your project for revenue's sake. But at some point, constant compromises point to flawed management.

Pica_soO 98 days ago [-]
If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.
jrochkind1 98 days ago [-]
The problem here is that you're making the organizational culture _worse_ while you make the code better. And it's organizational dysfunction that led to your situation in the first place.

It's a dysfunctional organization that doesn't let you write quality code without lying (assuming you are correct that this is ultimately counter-productive for the organization's goals), and most every dysfunctional organization I've seen is characterized by lack of transparency and truth internally -- nobody knows what's really going on, so there's nothing to do but political games. I think that lack of internal honesty is a cause, not just a symptom. So your workaround to let you do quality work despite being in a dysfunctional organization, misleading your peers and/or managers/administrators, makes the organization's dysfunction even worse, making it even harder to do quality work. In another kind of vicious cycle.

After a bunch of years of programming professionally, I've come to the conclusion that my job includes not just trying to make the code better, but trying to make the organization better too. The same way you've got to 'fight' for quality code, you've got to 'fight' for healthy (honest and respectful) organizational culture.

There are some (many) places that are so dysfunctional that they seem hopeless, and maybe you can't easily leave and find other employment. You've got to do what you've got to do to stay sane (and keep your mind from dying) and I don't fault people for their coping strategies in such an organization, but I think misleading/lying (which is really just a kind of 'political' game of it's own) to give you space for code quality is likely to lead into a vicious cycle of descending badness all around, not ultimately leading to increased job satisfaction.

Pica_soO 97 days ago [-]
Your definition of fighting for a better organisation, boils down to replace people who are apt at nothing but political games with people who are apt with engineering knowledge.

You cant do that, unless you have a little island of sanity at the top, giving you a lifeline and air-support. Sorry, i for once m not good at office version of the game of thrones.

noxToken 98 days ago [-]
So what's the alternative to lying for what you hope is the greater good?

This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them.

I'm not saying that lying is preferred, but what else can one do?

crdoconnor 98 days ago [-]
You need to flip the script on the problem. It's no longer a technical problem, it's a management problem.

Management problems are solved with spreadsheets that show concrete numbers going up or down.

At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.

At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.

Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.

After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".

If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.

Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.

jrochkind1 97 days ago [-]
I have not completely figured out what to do, but I'll say that if you leave because the organization is not interested in producing quality code and you don't want to work for such an organization, and they were unwilling to give you time (ie money) to produce quality and maintainable code -- the problems they have maintaining the code after you leave, having made efforts to educate/convince them of this fact and failing, _are not your fault_ and _not your problem_.

The tacit knowledge you take with you, when they were not willing to give you enough time to share/document this knowledge, or produce code that was more transparent, despite your efforts to tell them the consequences -- are _not_ your problem. Don't get Stockholm syndrome.

I realized at one job that I kept busting my ass to cover up for management failures (that I wouldn't get credit for saving them from)... they would NEVER LEARN. I was enabling terrible management and a toxic environment. They didn't even _realize_ I was saving them from themselves (and if I'm wrong and they were right and I wasn't, all the more fine it was for me to leave).

justin_oaks 97 days ago [-]
I just left a job where I knew that management would never learn. That was my primary reason for leaving. All other problems could have been fixed IF they would listen to the employees and/or learn from their own mistakes.

Alas, it was not meant to be. I feel like I was an enabler because there were a lot of things that I held together despite not receiving any support from management.

s73v3r_ 97 days ago [-]
If the organization doesn't care about code quality, then they don't deserve talented engineers with domain knowledge.
ConceptJunkie 97 days ago [-]
You're absolutely right, and my immediate bosses have dedicated themselves to laying down the law that good work requires more time. We live in a culture where there is a lot of technical debt inherited from a culture that used to be much worse than it is now, and I think we've made some progress on the front of not increasing the technical debt, by insisting on the resources to do things right. Now, reducing the technical debt is another matter.
marmaduke 98 days ago [-]
I don't know why this comment is in gray. I have been repeatedly pressured to "make it run on GPUs" and needed to spin some fiction to buy time.

In the end, if your superior tries to micromanage but doesn't understand the details, then a lie woven from bits of truth, if it helps achieve a goal, is morally indistinguishable from the whole raw truth.

majewsky 98 days ago [-]
It's sad that this gets downvoted, because it's the only realistic approach in such a situation (which is also sad).
DanielBMarkham 98 days ago [-]
I've seen a lot of teams in a lot of organizations, both bad and good.

Good teams cheat in bad organizations. That's why they're good teams. Whatever your metric, code quality, quality of life, being kind and supportive -- in organizations that pervasively do it bad, good teams cheat in order to do it well.

I think the trick is that only a small group of people know that they cheat, otherwise some mid-level manager would come down on them, hard.

leibnizwasright 98 days ago [-]
Yes, I don't see this a problem, normally releases get delayed, if you get more time to develop better, then why not? I always saw testers talking with product owners and managers about one or other developer that was slower but had delivered less defect.
ConceptJunkie 97 days ago [-]
I know that feeling. I'm one of those developers that is slower than a lot, but I also know from long experience that when I deliver something, it's solid. It's not that I don't make mistakes, but that I work in a way that helps to minimize them when I do make them. It takes me longer to get things done than the hotshots, but there will usually be fewer problems and the problems that do exist will usually be much shallower. And unlike a lot of people my work contributes to a net decrease of technical debt.

I'm not saying this to brag, but to emphasize that this is what it takes to do quality work.

brazzledazzle 98 days ago [-]
The downside to this approach is people. You risk other (well meaning or otherwise) developers trying to help fix your misunderstanding or telling your supervisor that you need help. Others may need to be in on it and sometimes that sort of environment breeds cut-throat behavior. If the business has the power to dictate unreasonable requirements people that break ranks to tell them what they want to hear can gain a political advantage.
mikekchar 98 days ago [-]
People have different situations in life and the range of options that you have as an employee can vary pretty dramatically. However, here's how I tend to cope with these situations (in order of preference):

1. If I don't get the time to do what I think is necessary, then I lobby to make sure that it's my decision about how much time it takes. You're not going to get handed this on a silver platter, but the main argument is that as a developer you are making a good salary. The person paying that salary should get the best value from that money. If you have to do your job in handcuffs, you're not going to be able to give the best value.

2. If I'm not in a political situation to do #1 (and you should probably try to make sure you are before you actually stick your neck out), then I will note the constraints I have to work under. Making a project succeed when everything goes exactly as you want it to is relatively easy (well, TBH, I think it's never actually easy, but you get my point). What makes a great developer is making the project succeed even when you don't have everything your own way. So find a way to succeed with the constraints that you have. If you fail, make sure to make it obvious which constraints are causing the most problems. Usually after you fail you can get some extra leeway on those issues. Work on the issues one at a time, most important first. Eventually you can usually promote yourself to option #1.

3. If I can't do #1 and there is some reason why #2 fails (and I can't fix it), then I will go elsewhere. No point in sticking around in a place where you can't succeed. Wish everybody great luck. Express remorse that you couldn't get the kind of success that everybody wanted. Thank people for the opportunities that you had.

4. If I can't go because I have no other job, or I need to stay because my visa says so, or my spouse will go crazy from stress if I switch jobs, or a million other possible reasons... I'll keep working and keep studying exactly what's causing the problems. It's easy to conclude, "Joe is breaking everything. I hate Joe" (I only picked the name Joe because to the best of my recollection, I've never worked with someone named Joe). But you're stuck and you might as well learn about the situation in more detail. Wait and watch. I hate waiting. Man, do I hate waiting. But eventually it will pay off. Opportunities are out there. Your job is to recognise them.

That's it. Don't lie. You'll only get found out and then make your job a hundred times harder. Don't get dragged into petty politics. The job is hard enough without drama. Play it straight and give everyone the best chance they have to understand what you are doing and cooperate with you. Don't undermine people. Just do your best. It's not always easy sailing, but learn how to navigate rough waters and you'll be fine.

swaqny 98 days ago [-]
bethly 97 days ago [-]
It's not even lying: the cycle is red-green-refactor, not red-green-done. Knowing when to extract functionality (and when to inline functionality) is part of our job, not a management concern.
bethly 97 days ago [-]
I think we tend to forget this because we so often muddy management and technical work, but management's job is to tell you what to build. You are the professional and it is your job to know how best to build it.
Terr_ 97 days ago [-]
You can try, but then your meticulously documented ticket about why it's a very bad idea to put SQL query fragments into "hidden" HTML form elements never gets prioritized into the sprint.

Meanwhile, the same outsourced developers are making even more things you haven't found yet for whatever managers have the most political clout this week.

logfromblammo 97 days ago [-]
You build version 1 to throw away, version 2 to be upgraded, and version 3 to be maintained.

If you never get to version 3, you never get the opportunity to worry about code quality.

justin_oaks 97 days ago [-]
Every company I've worked at will ship version 1 to production and proceed to build on top of version 1 forever. Of course, by version 1 I mean "the proof of concept I showed someone else".
logfromblammo 97 days ago [-]
A log can dream, can't it?

It's the classic bait-and-switch of corporate development. They get you in the door by pretending they have a rational process, and wait until you're invested before dropping the facade.

I, too, have never worked for a company that ever considered retiring software ahead of immediate necessity. Generally, it's always "we don't have time to do it right in the first place, because we're too busy fixing all the stuff that is broken right now."

jimjimjim 97 days ago [-]
i used to be a software archeologist at a previous job. dig a small hole and uncover the artifacts and ruins of a previous project civilization.

please, for humanity, write documentation. even better if it's after the code is written. why does the payments-smart-broker have a direct connection to the translations database if it doesn't have a ui?

97 days ago [-]
mempko 97 days ago [-]
It doesn't matter how pretty the code is if it does the wrong thing. Software quality is the interface , not the 'code quality'. Usually code quality helps build higher quality software, but it isn't sufficient.
Ocerge 97 days ago [-]
I hit almost this exact situation at my last gig. It came down to one of two things: was I okay with complete job security while being completely bored and apathetic all day, or would I take a bit of a leap of faith if it meant getting out of a rut? I chose the latter and it worked out. Maybe if I was a higher-up I would have tried to fix things, but it wasn't really my responsibility at the time. I'm not completely absolved; I could have tried harder to institute things like PRs and linters, but my give-a-fuck was far below the threshold it would have taken for me to really take action.
sseth 97 days ago [-]
When code quality is hard to enforce, one approach is to at least ensure that the design of public APIs, and boundaries between components reaches some level of quality. This is usually a smaller surface to monitor than the entire code base, and it allows islands of good quality to emerge. Good boundaries also will allow for easier refactoring over time of the really bad code.
myf01d 97 days ago [-]
This is the second post from this website to get upvoted to the frontpage within 48 hours. I hope this is natural.
realworldview 98 days ago [-]
Ahhh, life. If only everything were perfect. Keep pushing but don’t be surprised by the pushback and despondency. But keep pushing, for yourself, and others who want to care.
bryansum 97 days ago [-]
One huge problem is that there’s no context-indepedent definition of quality code, and criticisms often suffer from hindsight bias.
bethly 97 days ago [-]
This is why Sarah Mei's idea of Livable Code is so exciting to me: it talks about context-dependent quality code, and lets us talk about developing the context needed to move our definition of "quality code" to a more effective/more reliable/faster/faster-to-develop place.
swaqny 98 days ago [-]
ataturk 98 days ago [-]
What the author is too young to realize is that there is no development path for him(?) as a programmer. Companies don't care if you have time off or hobbies, or a wife, or anything. They don't hardly give a shit that you need to breathe air.
jbrooksuk 98 days ago [-]
This is why I’m keen on automating code standards/quality away. We’ve recently launched JS, CSS and Vue.js support in to help more developers standardise their code.