Sign in to follow this  

Code quality at work

This topic is 395 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Don't you feel when you're working on your games, that you make high quality code compared to the shit you see everyday at work ?

 

I'm a PHP developer and literally EVERY project I worked on had suber-shitty code, with retarded useless/duplicated/unreadable parts. I feel so bad for the developers who made that. I know sometimes the deadlines are shorts and you must rush it. But it feels really tiring to see the same shit after working in 5 different companies.

 

Don't you think it happens because of employers thinking developement can be done by any beginner ? Developer is often associated with "code monkey" (at least in France) and employers doesn't seems to understand that there are huge quality differences between the complete noob who made his personal website and professionnals with 5+ years of experience...

Edited by xxFuttBucker444

Share this post


Link to post
Share on other sites

Hah, opposite here.  I will program much sloppier on code for one of my hobby games.  Especially if it's a simple game and not a complex one.  At work we have code reviews before check-in, and have strict coding guidelines, as well as unit, functional and performance tests.

Share this post


Link to post
Share on other sites

Yeah it depends what the work culture is like. I've worked at places where the average talent was terrible and everyone coded like a high-school drop out from 1994... 

But I've also worked at places where the leads were amazingly good, and everyone strived to do a good job and become a better coder.

 

I generally write much better code at work, and then write really sloppy "seat of your pants" code on my personal hobby projects :lol:

Share this post


Link to post
Share on other sites
I see both good and absolutely horrendous code at work. It's mostly just over-engineered though. At work I focus on creating clean, simple, readable and documented code.

I write both clean/idiomatic and unorthodox/batshit-insane code at home, just to see what kind of craziness is possible and whether it makes my life easier or not. Experiments that survive these tests may be cleaned up and adapted and then used at work. Edited by Nypyren

Share this post


Link to post
Share on other sites

We've adopted new methodologies at work which I've carried over to my hobby projects, and similarly I've used hobby projects to learn new ideas that I've then suggested we adopt at work. There's more formality in place at my work, eg: Continuous Integration, Gated Checkins, the occasional code review, but there's not a "Work" and "Home" version of me as a developer, there's just me. :)

Share this post


Link to post
Share on other sites

When I see bad code at work I flag it for the next weekly code review meeting, where everyone can present whatever crappy code we see in the project and arrange to get it fixed.

 

When nobody flags anything we pick some randomly chosen files that haven't been reviewed recently and pick those instead.  We look for patterns that have changed or been created, coding style changes, dead/unused code, abstractions that can be moved up, consider creating or flattening or modifying inheritance hierarchies, renaming items, and more.

 

Whatever gets reviewed gets a comment at the top with the date, like: // Reviewed 2016-11-10  which prevents files from being reviewed too frequently -- but we still review them if they need changes -- and the comment lets us identify files that haven't been reviewed in a long time.  A simple grep searching for files that don't contain "// Reviewed 2016" gives great candidates for files to review and make current.  

Share this post


Link to post
Share on other sites

I usually see much cleaner code at work but, then I tend to work at companies that have very strict Agile systems in place.  

No code is started until a full set of Acceptance Criteria is written.  

All systems and interactions are designed by an architect.  

Full suit of unit tests have been written up front.  

Code is written and then a pull request is created which cannot be merged until not less than 3 people have reviewed and approved it.  

This review won't just take into account the newly written code but any files that have been touched by the change (the policy is always to leave code in a better state than you found it).

Once merged it will kick off an automated build that is sent directly to a DIT who will then write a full suite of UX automation scripts which once committed will send the build into the continuous integration pipeline.

Of course even in the perfect world there is the occasional need for a quick hack but this only happens if the team agree on it and it is added as "technical debt" story which has super high priority in the next sprint.

 

 

 

One thing worth pointing out though is that in all of this cleaner code does not mean better code.  You can have the most beautiful code in the world with an extensive suit of tests but, in the grand scheme of things you'll get just as many issues raised by QA as you would if you work in complete hack shop.

Edited by Buster2000

Share this post


Link to post
Share on other sites

My code at home is far better than what I work with. That's because at home I have as long as I like to refactor things or do them the right way. In the real world (or at least the part that I inhabit) the publisher doesn't pay to make your code look nice and they often don't care if the code is usable for future projects either.

Edited by Kylotan

Share this post


Link to post
Share on other sites
We deal with crappy code at work by having peer reviews. Each piece of code that is about to be merged have to be reviewed and approved by at least two teammates. If two of your colleges think that the code needs reworking, then probably they are right. This also helps everybody to get familiar with the entire code base. This slowed us down at first, until we have learned how to do it properly. Now that we have more experience, the peer reviews do not delay us much, but we have greatly improved the overall code quality.

Share this post


Link to post
Share on other sites

We deal with crappy code at work by having peer reviews. Each piece of code that is about to be merged have to be reviewed and approved by at least two teammates. If two of your colleges think that the code needs reworking, then probably they are right. This also helps everybody to get familiar with the entire code base. This slowed us down at first, until we have learned how to do it properly. Now that we have more experience, the peer reviews do not delay us much, but we have greatly improved the overall code quality.

 

I think it's a very good practice ! It may feel a by annoying to have every single line verified by someone else (less "its my code i am proud of it" feeling) but it can only leads to better code in overall...

Edited by xxFuttBucker444

Share this post


Link to post
Share on other sites

There is a marked difference between programming/coding and software engineering as my professor use to say. You can get anyone off the street who read some book/tutorial on how to program and have them write code. Does this translate directly into good quality code? probably rarely so being a programmer does not mean that one necessarily have the skills to design and implement ( the coding ) high quality software. I'm not advocating that any formal training is necessary for either, but being able to code does not imply being able write good software. The thing I'll try to impart is that if you are aware of the parties involved with the code in question, try to spark an open( non-confrontational )  discussion on the topic, if time permits and see how it goes. In the end we are all here to learn and you would be surprised how often people do things just out of habit, and if you could open their minds to a different approach, you probably could effect some change for the current environment you are in.

Share this post


Link to post
Share on other sites

Code reviews definitely help with code quality.  Having software that lets one add comments on any line, and updates with changes is super helpful.  And having others who are willing to go over changes with a fine toothed comb helps a lot a well.  I've noticed a big difference with code reviews with a team that has some very attentive reviewers, to teams that sort of do hand wavy, "Yeah sure, whatever, looks good"

Edited by ferrous

Share this post


Link to post
Share on other sites

Code reviews help with quality but you're still constrained by time and resources. If you have to ship a feature in 5 days that would take 8 days to do well then it doesn't matter how many people read it and complain on day 5.

 

Also, I think there's probably more benefit from getting extra eyes on the code and the architecture long before you're ready to check in. How to do that effectively, I don't know. (Pair programming drives me mad.)

Share this post


Link to post
Share on other sites

 

We deal with crappy code at work by having peer reviews. Each piece of code that is about to be merged have to be reviewed and approved by at least two teammates. If two of your colleges think that the code needs reworking, then probably they are right. This also helps everybody to get familiar with the entire code base. This slowed us down at first, until we have learned how to do it properly. Now that we have more experience, the peer reviews do not delay us much, but we have greatly improved the overall code quality.

 

I think it's a very good practice ! It may feel a by annoying to have every single line verified by someone else (less "its my code i am proud of it" feeling) but it can only leads to better code in overall...

 

 

This isn't directed at you, but more of a general comment.

 

"its my code" is a toxic attitude in a workplace. You need to stamp that out.

 

If you're being paid to develop software, be professional about it. Accept criticism and view it as an opportunity to learn. 

Share this post


Link to post
Share on other sites

 

 

We deal with crappy code at work by having peer reviews. Each piece of code that is about to be merged have to be reviewed and approved by at least two teammates. If two of your colleges think that the code needs reworking, then probably they are right. This also helps everybody to get familiar with the entire code base. This slowed us down at first, until we have learned how to do it properly. Now that we have more experience, the peer reviews do not delay us much, but we have greatly improved the overall code quality.

 

I think it's a very good practice ! It may feel a by annoying to have every single line verified by someone else (less "its my code i am proud of it" feeling) but it can only leads to better code in overall...

 

 

This isn't directed at you, but more of a general comment.

 

"its my code" is a toxic attitude in a workplace. You need to stamp that out.

 

If you're being paid to develop software, be professional about it. Accept criticism and view it as an opportunity to learn. 

 

 

This 100% It's up there with "This is the way it's always been done, this is the way I'll keep doing it".

 

At the end of the day you should be proud of what you accomplished, but you should understand that almost nothing is perfect.

Share this post


Link to post
Share on other sites

"its my code" is a toxic attitude in a workplace. You need to stamp that out.

This 100% It's up there with "This is the way it's always been done, this is the way I'll keep doing it".


Unfortunately, those attitudes are difficult to purge when the person is someone in charge or a senior developer who doesn't think younger/less experienced developers are "peers." I am optimistic that it isn't impossible in either case, though. Edited by Oberon_Command

Share this post


Link to post
Share on other sites

Problems with work code:

  • Deadlines: Whether it's someone yelling at you or you just being afraid you won't get something done in time, there's almost always a point where you'll throw together horrendous code you think you'll fix later and then 6 months later, hey it's still there!
  • Differing Opinions: Code review can be good but what do you do when someone just disagrees with you on what is nice looking code? Working on your own project that isn't ever a concern since you are the master of the universe.
  • Being Programmers: Most programmers want to try and improve, they'll write code for awhile then have that moment of "man this looks terrible, I should write it differently next time." Or they end up refactoring it right then and there, sometimes making a bigger mess.
  • Grandfather Clause: Often you just end up stuck with very outdated code and have to hook up some horrible monstrosity to communicate with it. Usually a bigger problem at work vs home, where you can allow yourself to redo large systems.

That said you can write some pretty bad home code too, I hate to admit it but often trying to adapt new coding patterns to make my code more pretty or readable or accessible has just ended up making it more of a mess to me. I know everyone around here tends to throw bricks at each other over code style but usually the most important rule is that something works.

Share this post


Link to post
Share on other sites

Problems with work code:

  • Deadlines: Whether it's someone yelling at you or you just being afraid you won't get something done in time, there's almost always a point where you'll throw together horrendous code you think you'll fix later and then 6 months later, hey it's still there!
  • Differing Opinions: Code review can be good but what do you do when someone just disagrees with you on what is nice looking code? Working on your own project that isn't ever a concern since you are the master of the universe.
  • Being Programmers: Most programmers want to try and improve, they'll write code for awhile then have that moment of "man this looks terrible, I should write it differently next time." Or they end up refactoring it right then and there, sometimes making a bigger mess.
  • Grandfather Clause: Often you just end up stuck with very outdated code and have to hook up some horrible monstrosity to communicate with it. Usually a bigger problem at work vs home, where you can allow yourself to redo large systems.

That said you can write some pretty bad home code too, I hate to admit it but often trying to adapt new coding patterns to make my code more pretty or readable or accessible has just ended up making it more of a mess to me. I know everyone around here tends to throw bricks at each other over code style but usually the most important rule is that something works.

Yep, welcome to the world of people giving you money to write code. 

Share this post


Link to post
Share on other sites

My code at home is far better than what I work with. That's because at home I have as long as I like to refactor things or do them the right way. In the real world (or at least the part that I inhabit) the publisher doesn't pay to make your code look nice and they often don't care if the code is usable for future projects either.

 

This is also true for me. Managers have different concerns then most developers, they need respect budget and deadlines. Some are just a bit too shortsighted sometimes. We are spending more time dealing with poorly organized code on a regular basis then it would have taken to just fix some things in the first place. At some point, you accumulate so much problems that it becomes impossible to even do a simple modification and then, you need change big things.

Share this post


Link to post
Share on other sites

Don't you feel when you're working on your games, that you make high quality code compared to the shit you see everyday at work ?   I'm a PHP developer and literally EVERY project I worked on had suber-shitty code, with retarded useless/duplicated/unreadable parts. I feel so bad for the developers who made that. I know sometimes the deadlines are shorts and you must rush it. But it feels really tiring to see the same shit after working in 5 different companies.   Don't you think it happens because of employers thinking developement can be done by any beginner ? Developer is often associated with "code monkey" (at least in France) and employers doesn't seems to understand that there are huge quality differences between the complete noob who made his personal website and professionnals with 5+ years of experience...
 

 

I find that most people -- myself included -- think just about any code written by someone else is shit. It's just a lot easier to write code than to read it.

 

As far as employers are concerned, they don't care about your code unless it's not working, or costing them money.

Share this post


Link to post
Share on other sites

This topic is 395 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this