7 ms·

I would be careful with some of the responses here. Over my career I've found that a significant subset of developers struggle with unfamiliar codebases. Someti

• ashrk 8y ago
  No (or long-broken) tests and no easy (at least partially automated and otherwise documented) way to build and/or run the code locally are the norm for others' codebases I've inherited. Those two things qualify it as "awful" I'd say, all on their own. Especially in languages like Ruby or JS where you're practically crippled in an unfamiliar codebase without tests and/or being able to poke around in the running application. Both being absent is a near-perfect signal there are tons of other problems, of the screw-up sort and not the we-had-to-cut-corners-for-actual-reasons sort. Comically bad security holes, actual or implicit (framework-created) SQL queries in a for loop for no good reason (well, because the developer had no idea how to use SQL, and hadn't developed an appropriate allergy to unnecessary network communication, are probably the reasons), hilariously misguided attempts to fix the wrong thing to improve performance ("we'll move it to jruby!" well sure but your actual problem is you chose an inappropriate database and are using it poorly, but at least you made your build pipeline worse for marginal benefits, so there's that). Ruby in your node project just to run a very basic task queue (!?). Et c., et c., c-beams off the shoulder of Orion, tears in the rain, et c. Inheriting something even half-decent is really, really unusual. I wouldn't bad-mouth half-decent. I just rarely see it. [EDIT] this probably varies a great deal by platform. I imagine it's a bit less common to have a total train-wreck of an iOS app, to pick another platform I've worked on, than something server-side.
  • ericb 8y ago
    > we'll move it to jruby! Hahahah Oh man, that's great. BTW, we had people who did this. Our performance is 2x better with half the servers after we undid this "optimization" at our org. I suggest benchmarking first.
  • swerveonem 8y ago
    Being able to solve those problems like "it ain't no thing" is part of being a senior developer.
    • ashrk 8y ago
      Sure, and man are the easy wins satisfying. Fixing shitty data access methods/patterns is one of the easiest ways to get a "WOW!" out of a client or product owner if you're stuck in the low-visibility silo of backend dev[0]. I've just been repeatedly surprised over the years at how very, very many people are making real money, and consistently finding work, yet don't seem to know which way is up. And I don't mean greenhorns, though often they're given comical levels of responsibility (typically by the cash-strapped or cheapskates) resulting in some real messes, which has a similar effect to when an incompetent "lead architect" or an experienced team nonetheless without a clue between them is set loose, which is just as common. I harbor no ill will toward these folks. Hell, selfishly, I'm glad there are so many. Having half an idea what you're doing is guilt-inducingly easy, pays amazingly well—especially after the confidence-boost and resulting swagger and negotiating attitude that comes with seeing this kind of thing over, and over, and over, for years on end—and it's disturbingly easy to be a or the "smart one" in the room when you're kind of a dummy, in fact. [0] Dear backend devs: if you don't simply love backend work and/or if you aren't very well appreciated compensation-wise, and especially if you have long-term career aspirations that involve shifting more toward the biz/architect/management side for the extra social status and higher late-career pay (in most of the industry outside the huge West-coast tech companies, anyway), consider moving to more high-visibility pastures—though ideally not web frontend, as, incredibly, it's still a trash fire and comp is so-so, mostly. Unless you just like trash fires, which some people do.
      • 8y ago
• ConceptJunkie 8y ago
  I don't know about you, but I've rarely worked on a codebase that _wasn't_ awful in some way, and I am definitely not early in my career. I've come to the conclusion that most programmers are simply awful at their jobs, and the developers that can write clear, concise code are a small minority. I've known a few, but not many.
  • maxxxxx 8y ago
    Especially in big companies it's really hard to keep your code concise. I have often started with a very clean design that totally feel apart when new requirements came in. If you give managers the choice to hack it into the code in 1x time or redesign the code in 2x time most of them will vote for the first option. Go through that cycle a few times and your code will be a big mess
    • jeffwass 8y ago
      This 100%. I’ve worked on several codebases over the years where a mgr said “here’s a special case, inputs of (foo, bar) should give baz2 not baz1. Coder whips up a hacky workaround to that very specific ask in the simplest place possible, not the right place. A few dozen requests come in like this over the months. Overrides and exceptions are now scattered all over the code base, without any semblance of order, functions no longer do what they advertise because data is modified downstream, etc. Sometimes the time to redo it right is worth the investment in terms of future maintenance. Other times it’s too foregone and you have to bite the bullet and stick with the mess.
      • jehlakj 8y ago
        It's hard to blame them. I've been in similar situations multiple times where a requirement seems simple enough on the surface that you only get a few hours to work on it. But it's actually not that easy to write it cleanly. That hacky workaround you're talking about? Well, my task depends on it. The workaround too depends on another hack. With the amount of time I have to work on it, it's a no brainer. Earlier in my career, I tried to fix them, but they started to break other "hacks" and down the rabbit hole I go. Sometimes it's just not worth it.
• djstein 8y ago
  > unfamiliar and less than ideal design patterns and coding practices. is this not what awful is?
  • maxxxxx 8y ago
    With that attitude anything a few years old will be called "awful", especially the latest, best shiniest code you are writing today.
  • vvillena 8y ago
    IMHO any non-trivial codebase will be awful in some parts. Codebases tell only half the story, and a programmer needs to also inherit the mindset that resulted in the code. Until that happens, there will be a research phase that will result in all the code being triaged multiple times, so the new coders can decide if the piece of code under triage is good, bad, or there's no way to know yet.
  • bunderbunder 8y ago
    The thing there is, all design patterns and coding practices are less than ideal. People pick the best way they can come up with at a time and place, and everything is hunky-dory for one fleeting moment, and then the moment is gone. Any code that's good enough to survive will see the world change around it, until you've got a system that was developed for one niche and then spent years evolving into a new one as business and technical requirements changed, and will have plenty of quirks to show for it. A good programmer can deal with that.
• manicdee 8y ago
  Yeah nah. We don’t describe code as “awful” because we truly want to rewrite from scratch. Code can be quite awful simply because a company has a high developer turnover due to hiring practices (you can code? Good, write our payroll system) and management (the bearings will continue until morale improves). As a result you end up with every function using different nomenclature, different approaches to encapsulation, differing levels of compliance to Demeter, bizarre side effects because they made sense in the one day that developer was allowed for that feature, and so on. So “less than ideal patterns and practices” does indeed count as “awful” code where the maintainer has to learn a new coding style for every file in the codebase.
  • jehlakj 8y ago
    Agreed. It's impractical to incorporate "ideal patterns and practices", but competent developers can get pretty close. Having said that, I much prefer working with code that is very simple and redundant with a verbose API, than with a codebase that is overly refactored and abstracted. Finding the balance of the two extremes would be my definition of an ideal pattern.
• sidlls 8y ago
  Generally I agree, but there certainly are exceptions. When it's a code base "nobody" can understand and that no other team or developer wants to maintain because of its complexity or infamously poor prospect for maintenance, that's a sign of a poor codebase.
  • deleted 8y ago
    [deleted]
• vorg 8y ago
  Most programmers working in a business know which codebases are the good ones and which are the bad. It's very unusual for a programmer to be given a good codebase as they are the most sought after, and therefore much politicking goes into getting those. Your number 1 red flag just shows the developer isn't competent or willing to take part in certain types of destructive office politics.
• Nuzzerino 8y ago
  > My number 1 red flag of working with a developer, unless they are very early in their career, is hearing them describe a codebase as awful. Most really are not that bad and are usually just using unfamiliar and less than ideal design patterns and coding practices. So, what if in reality, the codebase IS awful, and the product itself suffers from delays and setbacks even on seemingly simple tasks? Still a red flag if a developer says the sky is blue? Maybe you're the red flag in that case?
  • james_s_tayler 8y ago
    Yeah my biggest red flag is people who fail to have a proper discussion about what color the sky actually is. Unfortunately people often aren't incentivized to discuss the actual color of the sky,but rather the color as either they would like to see it or that would suit their agenda the best.
  • ohyes 8y ago
    It’s always awful. That means it’s never worth it to discuss how awful it is. You’re probably working with people who helped produce the awfulness, and it pays to be empathetic towards your coworkers. Code isn’t produced in a vacuum and there are always external pressures for why this was hacked in rather than done correctly. It just kind of makes you come off as tone deaf and inexperienced. “My code is perfect and everyone else’s is garbage.” (It isn’t). There are always concrete things that can be done to mitigate some of the awfulness and improve a codebase. A good developer will identify the root causes and fix them. Discuss and identify actual problems and solutions rather than your considerable (and understandable) angst.
    • hinkley 8y ago
      > Code isn’t produced in a vacuum and there are always external pressures for why this was hacked in rather than done correctly. Everybody has reasons for everything they do. Even if those reasons were made up after the fact to match the evidence (everybody wants to be sane even - no, especially - when they subconsciously do crazy stuff). Anyone attempting self improvement has to first contend with the fact that their reasons are somewhere on a spectrum from wrong to excuses. From a business perspective if you can tell me why it’s helping the business that’s the only reason that matters. Also a very important life lesson to realize that the reason we did something isn’t a reason to keep it around. Sort of a “what have you don’t for me lately”. Hacking something four years ago to land a contract that saved the company isn’t a good reason to keep that code now. We did it because we did it, but we don’t have to keep it that way.
• rossdavidh 8y ago
  I think badmouthing the developer who came before you is not good. But, a long succession of good developers, can jointly produce a codebase which is awful. Part of this is simply the fact that it has changed hands many times. Part of it is decisions made that the developers were not able to control. There are many other possible reasons. But, although most developers are trying to do a good job, and I think it is bad form to badmouth the developer before you, it is often quite simply the case that a large and old codebase is, in fact, truly awful.
• Kalium 8y ago
  > But sometimes it is good old fashioned workplace politics. It is risky to take on an unfamiliar codebase as any problems are now your problems in the eyes of management. And it is, practically speaking, impossible to account for all edge cases and surprises that may exist in a legacy codebase. When I was a more junior engineer, I thought I would be appreciated as helpful when I demonstrated that I could figure out and become productive in a new and umfamiliar codebase quickly. This was indeed the case! For a while, at least. Over time, exactly what you predict set in. I was expected to account for all possible surprises in legacy code. In addition to being handed more tasks in legacy code, I was also expected to account for all edge cases and surprises in there. Being able to blame the previous developers, believed by management to be excellent and highly competent, would have saved me a lot of grief. Perhaps unsurprisingly, this did not exactly thrill me and lead to wonderful performance on the job.
• jiveturkey 8y ago
  most really are that bad. try this on for size: look at your own code from 4 years ago.
• informatimago 8y ago
  I agree that unfamiliarity should not awful a code base make. However, there are degrees, and probably thresholds. If your code to manage web site users is using string theory, despite the assumedly concise, elegant and refined code, it would make it awful to all programmers, but the two in the world who master both programming, web site user management and string theory. Otherwise, bad design patterns and bad coding practices definitely characterize awful code bases. But the worst, is when it’s so bad that you can hardly refactorize it.
• hinkley 8y ago
  The first step is admitting you have a problem. If you can’t acknowledge badness as a group then entropy takes over. I complain/observe about codebases all the time, especially on projects with an SLA. It’s bit like fire code. When the shit hits the fan you [don’t] want people wandering around trying to figure stuff out. Hallmark of a bad team (project management, really) is if the same three people are required for every emergency. The interesting thing about complaining is that nobody wants to talk to the optimist about problems. It makes them feel small and stupid. I find myself in the role of troubleshooter often, because I’m good at it, I acknowledge that the struggle is real, and at the end I try to summarize the experience, and diagnose where they went off the rails. When you see 20% of the team have the same stumble, the problem isn’t with them. If the stumble was expensive then it needs to be addressed rather than blaming the victim. Nobody wants to talk to someone who shames them, either. But I don’t believe in the classic rewrite. I believe in prevention and station keeping (don’t let it get that bad). The human brain can only deal with so much. If you want to keep adding to the project you have to keep cleaning old code and improving your practices. Slowly you’ll have a very different codebase, and a team where everyone senior can fix most problems. Edit: a word