70

I'm only a junior developer but my job forces me to work with really terrible PHP code (think about the worst PHP code you've seen; then think about code twice as bad). I usually try to fix bugs and fight with the codebase to add new features. Sometimes I'm ordered to get things working ASAP which more often than not involves dirty hacks.

The product was previously open source and I am concerned that it might go open-source in the future. I would be ashamed if someone (especially potential employers) could find my name next some of the changesets. What can I do to protect my good name?

I am not sure if this is relevant but I'll add that neither my boss nor my colleagues want to admit that the code is bad, but I'm not sure I can blame them for that -- for many of them this is their first job.

Ashamed One
  • 511
  • 21
    How are you forced to write bad code? Why can't you stand up, stop putting your name to bad code, and explain the problem, the solution, the cost in terms of time, effort, and money, and the benefits of fixing the problems now to your superiors? – Thomas Owens Jul 06 '11 at 00:30
  • 2
    Boss breathing down my neck encouraging quick and dirty hacks – Ashamed One Jul 06 '11 at 00:36
  • 17
    "encouraging quick and dirty hacks"? Encouraging? Which is worse. Your pride (and finding a new job) or sticking with this job. It may not be bad to stand up for what's right. What's stopping you? Threats of violence? Blackmail? Criminal proceedings? Seriously. What stops you from writing good code? Please be specific. And honest. – S.Lott Jul 06 '11 at 00:41
  • Can we see some samples of what exactly you mean with "bad code"? –  Jul 06 '11 at 01:14
  • 114
    If it's any consolation, even good code you write today will look bad to you in five years. – Kyralessa Jul 06 '11 at 01:14
  • 7
    face it PHP encourages "quick and dirty" by not discouraging it and making it easy to d matter of fact I would say PHP excels at "qucik and dirty" better than any other language, except maybe Perl, once that momentum is established it is hard to stop especially if management is encouraging the behavior as well. In the end code that appears to function, regardless of practices is more valuable to the company than no code at all. –  Jul 06 '11 at 01:18
  • @Thorbjørn: Where do I start? require's used like function calls, if there are functions they are 1000 lines long, code reuse achieved through copy & paste, no coding standards, error reporting turned off for development, the list goes on and on, but I should not be showing the actual code. – Ashamed One Jul 06 '11 at 01:27
  • None of these are "really terrible" by themselves. –  Jul 06 '11 at 01:30
  • 1
    @Kyralessa That's so true it brings me to tears :( And I'd squeeze the time scale to something more like six months. – Michael Jul 06 '11 at 01:55
  • 4
    Most times I see comments like this, it's inexperienced kids thinking they know it all, that everything that's in the least different from their preferred way the world should work is "bad". Without any indication otherwise, I have to conclude the same thing here. – jwenting Jul 06 '11 at 11:09
  • I know the feeling! I was forced to work with a really ugly codebase and a 'template system' that forced you to escape your HTML (<div class="some_class">) in May. Needless to say I did not put my name in that code. Luckily the chance of this code being open sources is very slim. – Emil Ahlbäck Jul 06 '11 at 11:12
  • If the examples I gave do not indicate that the code is terrible, then I'm afraid I should consider career change. – Ashamed One Jul 06 '11 at 11:21
  • 8
    Sorry but there are right and wrong ways to write code. The right way uses standard industry practices; the bad way hacks together shit and says it "works". – Wayne Molina Jul 06 '11 at 12:20
  • 3
    @ashamed: Sometimes it's more important to have it quick than to have it good. (http://siryes.blogspot.com/2010/11/project-triangle-cheap-fast-good.html) – Satanicpuppy Jul 06 '11 at 13:55
  • 2
    "error reporting turned off for development" How exactly is error reporting done in PHP that this would ever be a good idea in the development stage? – JAB Jul 06 '11 at 14:07
  • 2
    @Jarrod: As much as I hate PHP, I do have to say, it's not the language's job to encourage decent code. (PHP actually discourages decent code, which is why I hate it, but that's another argument...) – Billy ONeal Jul 06 '11 at 21:06
  • @Billy, actually it isn't another argument, that is my argument :-) –  Jul 06 '11 at 21:20
  • @BillyONeal: When I see that Drupal encourages not to close Php files with ?> so that beginners will never see their mistakes (lot of blank lines at the end), and I could say 10x more... I just can say you're damn right, even though I love Php. – Olivier Pons Oct 26 '11 at 13:05
  • 1
    @Olivier: Blank lines at the end are not mistakes. – Billy ONeal Oct 26 '11 at 19:05
  • @BillyONeal: when you close your code with ?> and then let some blank lines, Php interprets those blank lines as HTML and then sends them, so you can't send headers anymore, that's why code with ?> and blank lines after may be considerered as an error, and it's a classical beginner's mistake. To avoid this, Drupal asks not to finish at all with ?>. And this is really bad for me, because it encourages to write bad code ("never mind, leave a lot of blank lines, no problem"). I hate that. – Olivier Pons Oct 27 '11 at 08:38
  • 2
    @Oliver: Leaving off the ?> is perfectly valid. It's the standard on most PHP projects I've seen. Yes, PHP interprets anything after that as HTML, and that is a mistake. But if you leave off the end tag, there's nothing treated as HTML. If you're that worried about a couple of newlines on the end of your source you've got bigger problems than PHP end tags. – Billy ONeal Oct 27 '11 at 15:03
  • @BillyONeal: I'm just trying to say that making code that helps beginners avoiding mistakes should not be the priority, because it may leave to bad code. Maybe concentrate on writing clean code and more understandable code (KISS principle) is more important than everything else. And when you develop with Drupal it's the exact opposite of KISS. That's all what I was trying to say. (Yes I've been working on Drupal for more than 2 months and if I wasn't paid that much I would have thrown that "thing" away almost from the beginning) – Olivier Pons Oct 27 '11 at 20:24
  • @Oliver: Newlines have nothing to do with more readable or cleaner code. I would call not worrying about something as insignificant as a few newlines following KISS. – Billy ONeal Oct 27 '11 at 21:35

10 Answers10

132

Rome wasn't built in a day, but you can be a good 'Boy Scout'. Every time you touch the code, leave it better than it was before. It doesn't take an extraordinary amount of time to use sensible function names, good coding standards and put decent comments in when you work.

I think the danger is thinking it's all or nothing. Just because you can't spend the time you want to write elegant code, doesn't mean you have to totally give up and write garbage.

Amy Anuszewski
  • 1,745
  • 2
    +1. You don't have to sacrifice everything you believe in just to make it a quick fix. – tdammers Jul 06 '11 at 06:04
  • 4
    +1: for all or nothing - very true. – Umber Ferrule Jul 06 '11 at 08:42
  • 3
    The Boy Scout rule in the wrong hands can exactly be what causes the problem, because the definition of 'sensible function name' of his superiour could be 'bolChkLst' (hungarian notation to meet the styleguide, ChkLst instead of CheckList because 'shorter is better'). Here are some Boy Scout Rule implementations i encountered at different jobs i tried not to follow: 'Join functions, to have as few as possible', 'dont carry arguments through 3 calls, use globals instead', 'use inline SQL in views to make it quicker' – keppla Jul 06 '11 at 11:06
  • 41
    +1 for Every time you touch the code, leave it better than it was before. – Qwerky Jul 06 '11 at 13:00
  • 3
    +1. If you have lots of clear improvements committed, anyone who actually looks at your contribution won't think you're a crappy programmer. Potential employers who assume you're crappy because the project is crappy aren't people you want to work for. – Matthew Read Jul 06 '11 at 15:13
  • 1
    I absolutely agree and want to emphasize the part about comments. The worst code in the world is no longer the worst if you've gone through it and added helpful comments every step along the way. I work on an old, bad code base and routinely have to make fixes. If I need to understand some hideous function, I research and understand it, then comment every line that wasn't obvious to me coming in. When you revisit that code in the future, it's still bad, but you can reread your old comments and just say "yeah... Ok, I guess it works" and keep going. – Stefan Mohr Jul 06 '11 at 15:39
  • The boy scout rule is great, but function names are better than comments. – byxor Dec 26 '16 at 13:49
  • 1
    This is hogwash. If OP spends time making code more maintainable, sane and less of an embarrassment, they will get reprimanded for wasting time by clueless project managers. It's frankly irresponsible to advise someone to get themselves in trouble. Stop pretending that the software industry isn't full of incompetents, bullies and morons. – user234461 Apr 09 '18 at 13:18
60

Agree with S.Lott from comments* (for once :) No one is forcing you to write bad code. The thing is, junior dev. often (this site is also to blame for that) get lost in best practices, "beautiful code", ... whatever you wanna call it ... and they don't get much done; or they get it done but waste a lot of time. By telling them to write bad code (which is code which also works) it gets than "through that", just makes them deliver something. As time passes that results that a (now no longer :) junior dev very quickly comes up with a quick&dirty solution, but spends the rest of the time improving it. And as time passes, you learn more, and at some point you start delivering quick&dirty solutions which are actually good code.

But, if you went your way and tried writing perfect code from the start you most likely would've spent a lot of time, and done almost nothing.

So ... write bad code, ... lots of it ... code that barely works, and then ITERATE. Every iteration a tiny bit better!

No one wrote the perfect solution the first time.

*this, were it shorter would've been a comment.

Christopher Mahan
  • 3,404
Rook
  • 19,909
  • 1
    +1 I strongly agree with this answer. I'd upvote you twice. – Vitor Py Jul 06 '11 at 01:16
  • 3
    I agree. This is a great way of cutting through "analysis paralysis," which can take hold as you try to reach the "perfect" solution to a problem. I wrote something similar on StackOverflow . – Kyralessa Jul 06 '11 at 01:17
  • 4
    +1. I have read this on programmers already (but don't know the source): two groups were tasked to create pottery within a given time frame. One to create an item of the best quality possible and one to create as many items as possible. In the end, the latter group provided items of better quality, because repetition is the path to mastery. Contemplation alone will get you nowhere. In the end, we all learn by doing and our fear of doing something wrong is what holds us back in trying, possibly failing, but definitely learning from our mistakes. – back2dos Jul 06 '11 at 01:32
  • 1
    As a corollary, use a repository! Even if it's just a personal one you've set up on your own machine. After you start using them, you realize how liberating it is to make a bunch of changes, find out it didn't work, and roll back. My personal fav is fossil – Spencer Rathbun Jul 06 '11 at 15:19
  • 1
    "So ... write bad code, ... lots of it ... code that barely works, and then ITERATE. Every iteration a tiny bit better!" What if you just never get to iterate because new projects keep piling on... and you start to realize that what you push out as alpha tends to stick around till the project dies. Which of course is sped along as a result of initially shitty code and lack of updating. I think it's these kinds of situations that lull many junior devs into thinking they need to write "beautiful code" from the get-go... – Serhiy Jul 08 '11 at 15:49
  • I'm sure I'm guilty of the "write beautiful code" the first time problem as a junior dev. I've gotten the point where my mind can come up with elegant quick & dirty solutions that scale better and are easier to maintain. +1 – sholsinger Aug 09 '11 at 20:23
  • This is correct but so many bad coders can use that sensible answer as an excuse. It's really painful for others, not just juniors. – ZenVentzi Apr 30 '20 at 15:58
40

Code comments are your friend here.

Whenever you feel like you have to write some cheap hack because of pressure, just say something like, "This code does X because of time constraints. Ideally, I would do Y instead. - Ashamed One, 5 July 2011"

Then if potential employers see it, they'll realize you prefer to write good code, but you're also willing to adjust your coding style to business needs. Most employers will see both of those as good things.

Bob Murphy
  • 16,098
  • 4
    Exactly. Comments and commit-messages too. I've never done it, but it would interesting to evaluate a developer based on nothing other than annotated changesets attributed to them in some vcs. – timdev Jul 06 '11 at 03:52
  • well, you can tell something about someone whose commit comments are "fixed", "done", "blahblahblah" :) – gbjbaanb Jul 06 '11 at 12:33
  • +1 I've done this several times and in case of peer developers it just works. – Jacek Prucia Jul 06 '11 at 12:37
  • 7
    I generally delete comments like that whenever I run across them. A comment marked as TODO or FUTURE-ENHANCEMENT might deserve to stay, but apologies are just garbage. – Kristopher Johnson Jul 06 '11 at 15:14
  • 1
    Agree with including an explanation as why a less than optimal solution was implemented (and what that solution might be) I do this from time to time. However I don't think it is anything to be ashamed of or apologize for. It just means there were more important things to do at the time you were working on that piece of code and that the given implementation was sufficient. – Justin Ohms Jul 06 '11 at 15:37
  • so don't forger to put a "@todo" before your apology – niahoo Jan 21 '15 at 13:31
10

It depends on how they force you.

In my experience,there are two possibilities:

You feel forced by a tight schedule, legacy code, etc.

In this case, as most of the other answers already say, it's up to you to 'optimize for coolness'. You may not have the time to rewrite the codebase to MVC, but as first step, for example, you can stop glueing your SQL by hand and instead write a nice execute_sql($query, $params), that lays the foundation for abstractions like fetch_customer($filter_params), etc. Remember, all the best practices are ultimately there that your boss gets a product earlier, so there is only a conflict in how much time to invest in the future vs in the now.

When you set the right context ('within 6 month, without getting extra time, i refactored the monolithic code to MVC') you should leave your name on the code, and try to be proud like a therapist, that teaches a stroke victim to say single words again.

You are explicitly ordered to implement it a way you deem unfit

The try to separate view from model does not survive the review, because 'it is too complicated, why dont you just do plain sql queries?'. Your execute_sql gets canned because 'a coder with discipline does not need that'.

This case sucks bad. In my experience, it usually comes with micromanagement and teamleaders who got promoted there for political reasons, not for their successes. The real problem is, that you are put in charge of something (the code) that you can't control (you have to do it their way). The best solution would be to solve the root cause (i.e, that you are treated as a grunt). The second best (and in my experience, the usual) solution is to quit.

The upside is, that in this scenario, your name isnt likely to get published anyway, because the team leader takes the credit for all success.

keppla
  • 5,220
  • 24
  • 32
8

I'm pretty confident your boss demands you deliver something fast, but not that you take any extra effort to make it deliberately bad. Which means that whenever you have a choice between really bad code and slightly less bad code, and both options would take you equally long to implement, you go for the slightly less bad option. That's the short-term solution, and it doesn't require any effort at all.

For the long term, talk to your boss. Explain how investing 15 minutes here can save hours there. Make sure you have convincing examples - not the type "if I did this and that here, my hope is that I would be able to do this other thing next year", but rather, "look, here I did this thing, and because of that, it took me three hours to find the problem there; if I had done it this and that way, the bug would have been apparent right away". A warning here: while elegant and maintainable code feels much better and more efficient, sometimes it isn't. There are situations where a sloppy quick-fix is perfectly justified: sometimes you are writing single-use code, sometimes you are keeping an outdated piece of junk alive, awaiting the real thing; sometimes, the benefit of a proper solution doesn't justify the effort (money-wise, which is all your boss is interested in).

If all else fails, go find another job.

tdammers
  • 52,636
  • 15
  • 110
  • 155
3

Nobody forces you to write bad code. You can turn this situation around and make it a positive. Pioneer change for policies and procedures. And you can't always be the "yes" man/woman either. If they say they need functionality x before the end of the day, tell them it is not feasible, but give justifications why indeed it is not. Where there is a problem, offer solutions. Not just a blind eye, or worse...adding to it.

Your dev shop isn't the first to have strict deadlines, while still having the desire to maintain well-engineered code.

  • 4
    -1: In the US, if your boss says "Write fast crappy code", and you refuse to do it, they can fire you. Disobeying a direct instruction to do something that's legal is grounds for involuntary termination. So while that may not be "forcing" you, the alternatives to doing what your boss says may be much worse. – Bob Murphy Jul 06 '11 at 01:19
  • It all depends on your approach. Ideally you would have a superior figure that would value your expertise and your judgement should be highly regarded. Often times the people dictating timelines aren't developers, and they should take into consideration what is possible and what isn't. Of course you could write "crappy" code under the covers, but the push back might be enough so that everybody is happy: good results from good code. –  Jul 06 '11 at 01:21
  • 1
    Ideal superior figures you don't actually work for are great, but the person who signs your paycheck is the one you have to please. Having bill collectors call at all hours when you're out of work really, really sucks. – Bob Murphy Jul 06 '11 at 01:28
  • Bob, I agree with you. I understand the "looking out for number one" mentality, but the ideal superior figure isn't so rare that it's not worth breaching if you feel as though you have this type above you. –  Jul 06 '11 at 01:31
  • 1
    There's more to it than raw self-interest. I've been a manager and entrepreneur, and I can assure you that if all the customer is paying for is quick-and-dirty, doing a good job that loses money will lead to people being laid off. I had to lay off an entire company once, and I never want to do it again. So while I'm definitely in favor of taking moral stands... writing crappy code usually isn't a moral issue, and at some point one must choose between personal preference and the practical issues of people having or not having jobs. – Bob Murphy Jul 06 '11 at 04:06
  • The point of writing good code is to deliver faster. I strongly believe that on a timeline longer than a day or two, good code written by an experienced dev will win the race every time. I'm not the only one that thinks this: http://martinfowler.com/bliki/TradableQualityHypothesis.html – PeterAllenWebb Jul 06 '11 at 12:29
  • @PeterAllenWebb I don't think that applies when the question is whether you write a quick hack or mostly rewrite a large and horribly coded system. To make a racing analogy: You say a marathon runner can beat a sprinter on a marathon, even if the sprinter can beat the marathoner in the 100m dash. I say that the marathon runner can't run a marathon faster than the sprinter can run 100m. – Matthew Read Jul 06 '11 at 15:19
  • 1
    I would almost never advocate a large-scale rewrite of a big system, but that doesn't mean that the code you write in the future has to be horrible. – PeterAllenWebb Jul 06 '11 at 19:13
3

Any company needs to find a balance between writing brilliant code, with extensive documentation and unit tests and getting products to market in a reasonable budget and time space.

The best code in the world doesn't matter if it obsolete before it is released.

Being pragmatic is about trying to find that balance. Getting features fixed quickly may be commercially essential at the moment, it doesn't mean it always will be.

It takes a lot of experience (More than most coders ever have), to get this balance right. It is very easy to go for either extreme. Finding a middle way is more difficult.

I'm not saying your boss is right. As a coder there is a temptation to try to constantly create beautiful code which is not commercially viable. Being mindful of this temptation may help you to realize that some of these hacks aren't too bad.

Most code after enough time will contain hacks for specific situations which were too costly to refactor into a general framework.

Jeremy French
  • 1,150
2

I'd like to add that you shouldnt just continue like you are doing it now, sayning nothing and just hacking and hacking.

You need to stand up and point at concrete code and tell them what sucks about it. Be specific and use code metrics to back up your claims. Nothing is more embarrassing than claim a code is bad when in fact its not, you just didnt understand what was being done.

I am sure there are many tools available free to use for php code analysis http://en.wikipedia.org/wiki/Code_analysis

Also, of course this http://en.wikipedia.org/wiki/Code_smell

Read it up, sum up what you can find in your application, and of course list alternatives. Its bad practice to just stand up and shout "I dont like how this is done" without presenting an alternative (preferably) better way to do it.

Quick hacks cost money. And dont see it as entirely negatively - You can learn a lot from this job now and can profit from the experiences you now make in your next.

hth

0

Before anything else, you DO use source control of some kind, right ? If not, start from there. It will help you first and be adopted by the rest of the team quickly.

If you have source control, you should not put your name in the code, just put the name of your company. It is common in bad code to put a revision history in the comments at the top of files, this is better delegated to source control.

Now, regarding the code quality, you will not be able to change it as a big bang approach. Slowly, one by one, add new approaches to different issues. If you do it right, it will SAVE you some time and you'll use it to make the overall quality better.

To give you an example of mine, I once arrived in the middle of a project with a Perl/CGI application where all HTML was in the code. The whole app was in a single file with no clear structure. Nothing was versioned. I started by configuring a CVS repo (no SVN available at the time), put a web interface on it for the customer. At first, I was handling the commits from my colleagues myself. Then, I split all methods in different modules (files). At that point, the colleagues started adopting CVS. Then, I moved the HTML out of the code. Then, every time I had to do a change in some part of the code, I took a bit of time to refactor some of it. In the end, the development velocity had increased so much that the customer was extremely happy. They would request a cosmetic change and instead of us telling them "it will take 2 days", I changed it on-the-fly in the dev environment.

This approach however will only work if you master the overall code well enough. If you don't understand the big picture, if some parts of the application remain unintelligible, it will make your job really hard.

One last thing, a complete rewrite is sometimes the only solution but it is usually very hard to justify its cost to management.

Eric Darchis
  • 101
0

Since you are a junior developer, this is actually a good thing. Being tossed into the middle of a big ol' mess of code will teach you far more about what not to do than only working on perfectly 'clean' code would. Take advantage of the situation and learn how to refactor the bad code and slowly convert it into something more managable. And dont complain about it having to be ASAP. Thats the point - learn to refactor and clean up code while doing things under a tight deadline. After all, anyone can write perfect code if they have endless time available.

GrandmasterB
  • 39,224