15

I work as an iOS developer in a small outsourcing company in a team of 4 people. We work on a project that started a couple of years before I and two other developers joined the company. Before that the project was mostly being done by one person.

When I started working on the project it was a complete mess. There was a lot of code repetition. I saw the same 500 of code coped to 20 different files with minor variations. Additionally, it wasn't exactly well organized: all UI creation code was mixed in the view controllers together with the logic.

I tried my best to refactor things here and there, eliminate redundant pieces of code, improve project's file structure and so on. It felt like the previous developer didn't really care about all these things or didn't have the experience. There was a time when I worked alone on a pretty big feature for a couple of months. Due to the nature of this feature I had to touch a lot of code across the whole app, so I did attempt to make some improvements.

When other developers joined the project, I noticed that they use a different coding style (sometimes a completely different style) and often don't use modern language features like property accessors (this is relatively new in Objective-C). Sometimes they would invent their own bicycles instead of using similar features of the framework, or transfer concepts from other programming languages or patters they learned into our code base. Oftentimes they can't name methods or variables properly because of bad English (Objective-C is a language where you make long names).

Sometimes I think if it wasn't for the IDE I think they would write all code with no indentation or formatting at all.

Basically, I hate the code they write. It's badly formatted/organized, and sometimes is radically different from the rest of the project. I feel very upset when they add their spaghetti to my piece of art and it affects my mood at work and my productivity.

It feels more and more like they can't be bothered to learn or don't care: they just do what's required from them and go home. I tried to give them a few tips when I had an opportunity (e.g. commented their PR or commits on GitHub). I once asked nicely to follow the coding style and formatting of the majority of existing code (sadly we don't have a formal coding style document). But it didn't work...

How can I address this situation without just focusing on 'bad company culture', 'inexperienced graduates', etc. and actually start to improve the situation.

  • 3
    What, if anything, do you have in the way of team leads / senior developers / managers? – Philip Kendall Nov 12 '16 at 9:59
  • 3
    "Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime" - instead of "simply doing your job" and refactor the small parts of the code you control, start teaching others a better coding style. Make sure you get some backup by the management for this, of course. – Doc Brown Nov 12 '16 at 11:00
5

Teach and Practice what you preach.

You know this stuff is important. You know the downside when it isn't done right.

Now the challenge is to convince others. This will not be done through a single conversation, a meeting, hallway conversations, tips or within a Pull Request.

This needs:

  • Public acknowledge by management that these items are important
  • Linters so that people can get together, hash out and agree on style and then let computers do the policing
  • Lead developers who fully buy-in and are willing to teach others
  • Meetings, demos, lunch and learns, etc to teach these approaches
  • People being measured on the quality items you mention during their reviews
  • Documented and published standards
  • Pull Requests having many reviewers
  • Pull Requests not being merged until code quality is high
  • Frequent code pairing
  • Group code reviews for complex PR's

In word it requires

Leadership

The good news is that all these activities are generally recognized as good practices so when you go to promote them or get buy-in from management you should have a good chance success and should be able to defend doing the right thing. Management might still not buy in however, that's another topic and question.

2

I've written a lot on this subject on SoftwareEngineering.SE in the past, and was in similar situations myself. Therefore, I'll attempt to give a few hints and highlight a few issues I noted when reading your question.

But first, let's talk about an important aspect: your role in the company.

Your role

You may have an explicit mandate from your boss to enhance things, and also a place in the hierarchy where other developers have to listen to your orders. Or you may be among peers, having the same role and the same authority, your option being only... well... an opinion.

In both cases, what matters is less your place in the hierarchy, and more:

  • What other developers think of you. If they treat you as an annoying guy who ask them stupid things, you won't get far. I've seen many cases where technical leaders and project managers had absolutely no influence on the team, because the team knew (or thought) that those “leaders” had no technical background required to take decisions they were taking. On the other hand, I've seen several developers who were actually listened by their peers, because they knew those developers are skillful and experienced.

  • How solid is your team and what motivates them. Imagine a company where every developer is paid for KLOC/month. Would anything you say about style matter to your colleagues? Probably not, because rare are persons who want to be paid less. In general, if this is not a team but just a group of persons working on the same project, you won't be able to improve anything.

Depending on that, you may decide whether it's worth the effort to make any change. If you have no voice and there is no team cohesion, just go look for another job. If you're known as a talented, respected developer and the there is a strong team feeling, you'll be able to improve things relatively easy, even if faced with the hostility from your boss or other teams.

In all cases, it is essential not to make pressure on your team. Work with them, not against them. Don't give them orders, but guide them towards the goal.

Now, the hints.

Style

I once asked nicely to follow the coding style and formatting of the majority of existing code (sadly we don't have a formal coding style document). But it didn't work...

Of course it didn't, since this is not the way it should be done.

  • Style is boring.

  • Following style is boring.

  • Writing coding style document is boring (and damn difficult; don't even try doing it unless you have worked with the language for more than ten years).

  • Reading style document is boring.

  • Reviewing code for style mistakes is boring.

  • Trolling that my style is better than yours is exciting, especially when there is absolutely no objective benefit of one style over another. Seriously, every sane person knows that the right way to write if (x) is the way I wrote it, not if(x) or if ( x )!

Therefore:

  • Don't do style reviews. This is the job of style checkers. Those cute applications have a few benefits over your brain: they check the entire project in a matter of milliseconds, not hours or days, and they don't do mistakes and don't miss style errors.

  • Don't write your own style standard. You'll do it wrong anyway, and your coworkers will troll you that you made bad choices.

  • Don't force developers to fix 2 000 style errors.

  • Do enforce style automatically on commit. Code which has style mistakes has no place in version control.

  • Do it from the beginning of the project. Setting up style control in an existent project is difficult to impossible.

For more on that, read the first section of this other answer on SE.SE.

Also:

  • Don't be too strict. For instance, writing jslint-compliant code is quite annoying, so it should be done exclusively when absolutely needed (or if all the members of your team are happy using it). The same goes for static checking tools; for instance, .NET's Code Analysis at maximum level could be very oppressive and depressing, while bringing little benefit; the same tool set at moderate level, on the other hand, proves to be very helpful.

Code reviews

Now that you don't need to bother about style during code reviews, you can focus on more interesting stuff: enhancing (vs. fixing) the source code.

Different persons react differently to code reviews. Some consider it an opportunity. Others hate it. Some listen to everything you tell them, take notes, and don't discuss, even if they could be right. Others try to argue on every point. It's up to you to find a way to deal with every developer according to her personality. It is usually helpful to:

  • Do code reviews in private, especially when the developer is junior and writes a really bad code.

  • Show that there is nothing personal: you are reviewing the code, not the person's skills.

  • Show the actual goal of a code review. The goal is not to show how bad a developer is. The goal is to provide opportunities for improvement.

  • Never argue. You're not here to convince, but to provide your expertise.

  • Never assume the reviewee is the only one who can learn something from a review. You're here to learn too, both by reading the code and by asking explanation about the parts you don't understand.

Once the code review is done, make sure the person actually improves her code. I had a few cases where developers thought that code review ends when the actual meeting ends. They leave and go back to their new features, trying to apply what you shared with them for new code only. Having a decent tracking tool for code review helps.

Note that independently of your particular role in the company and your expertise compared to others, your code should be subject to review as well. You shouldn't be the only one reviewing others' code either.

In a recent project where I worked as a technical leader, I had a hard time explaining to my coworkers that it's their role to do the reviews of each other's code, including mine. The fear of an intern who is about to review the code of his technical leader disappears as soon as he finds the first issues in the code—and who among us writes flawless code?

Training

Code reviews are a great opportunity to teach and learn some of the aspects of programming and software design, but others require training.

If you are able to train your coworkers, do that. If your management is hostile at the idea of training, do it informally. I've done such training sessions in a form of informal meetings, or sometimes even as a simple discussions, sometimes interrupted by management and pursued later.

Aside direct training, make sure you know well enough the books such as McConnel's Code Complete, and talk about those books to your coworkers. Suggest them to read source code of open source projects, give them specific examples of high quality code. And, obviously, write high quality code yourself.

Focus on context, not on persons

How can I address this situation without just focusing on 'bad company culture', 'inexperienced graduates', etc.

Those graduates have a goal: acquire experience, learn stuff, become more skillful. If, year after year, they write crappy code and know nothing about programming, it's probably because your team or your company is not giving them this opportunity.

If you're focusing on the fact that your team has inexperienced graduates, this won't help. Instead, focus on what you can do for them and with them. Code reviews and training are two of the techniques to improve the situation.

Bad company culture is a different beast. Sometimes, it can be changed. Sometimes, it cannot. In all cases, remember that you are part of this company, so you are part of the company culture. If you can't change it and find it inherently bad, sooner or later, you'll have to leave.

Get your metrics right

How exactly do you measure code right now? Do you measure the number of commits per day per developer? Or the KLOC per month per programmer? Or maybe the code coverage? Or the number of bugs found and fixed? Or the number of potential bugs caught by regression tests? Or the number of reverts done by Continuous Deployment server?

Things you measure matter, because team members are adapting their work to the factors which are measured. For instance, in one company where I had to work a few years ago, the only thing which was measured was the time one spends in the office. Needless to say that this wasn't encouraging to deliver better code, or to work smarter, or... well, to work at all.

Figuring out positive and negative reinforcement and adjusting the measured factors over time is essentially the leverage you have on team members. When done properly, it makes it possible to achieve results which won't be achieved by simple hierarchy.

The things which bother you, make them measurable. Measure them, and make the results public. Then work together with other team members to improve the results.

For example, let's consider that team members make too many spelling mistakes in the names of classes, class members and variables. This is annoying. How could you measure that? With a parser, you can extract all the words from the code, and using a spell checker, determine the ratio of words containing mistakes and typos, say 16.7%.

Your next step is to agree with your team on the target ratio. It could be 15% for the next sprint, 10% for the next one, 5% in six weeks, and 0% in two months. Those metrics are recomputed automatically on every commit, and displayed on a big screen in the office.

  • If you don't achieve the target ratio, your team may decide to spend some more time fixing spelling mistakes. Or your team may consider it better to compute the ratio per developer, and display this information on the big screen as well. Or your team may find that the goal was too optimistic, and that you should review it.

  • If you achieve the target ratio, the next step is to make sure the number of mistakes and typos won't increase over time. For that, you can create an additional task in your build which checks for spelling mistakes, and fails the build if at least one mistake is found. Now that you got rid of this problem, your big screen may be reused to show the new relevant statistics.

Conclusion

I believe that every aspect mentioned in your question can be solved through the techniques I included in my answer:

  • When other developers joined the project, I noticed that they use a different coding style (sometimes a completely different style)

    You had to enforce style automatically on commit.

  • and often don't use modern language features like property accessors (this is relatively new in Objective-C).

    Both code reviews and training are here to transfer your knowledge of the language.

  • Sometimes they would invent their own bicycles instead of using similar features of the framework

    Both code reviews and training are here to transfer your knowledge of the framework.

  • or transfer concepts from other programming languages or patters they learned into our code base.

    This is an excellent thing. Seems like an opportunity for you to learn from them.

  • Oftentimes they can't name methods or variables properly because of bad English

    Code reviews should also focus on proper naming. Some IDEs have spell checkers too.

  • Sometimes I think if it wasn't for the IDE I think they would write all code with no indentation or formatting at all.

    Of course they would. Style is boring and should be automated.

  • Basically, I hate the code they write.

    Remember from the code reviews part: “The goal is not to show how bad a developer is. The goal is to provide opportunities for improvement.”

  • It's badly formatted/organized, and sometimes is radically different from the rest of the project.

    Automated style checking.

  • I feel very upset when they add their spaghetti to my piece of art

    Wait, what?! Piece of art?! Guess what? Some persons (including you in six months) may find your code far from being a piece of art. Meanwhile, do understand that considering your work as a piece of art and their work as crap won't help anyone. Including you.

  • It feels more and more like they can't be bothered to learn or don't care: they just do what's required from them and go home.

    Of course they will do what's required from them. Remember: context, not persons and get your metrics right. If the context requires from them to become best at what they do, they will do it. If the context requires to produce as many KLOC per month as possible and nothing more, they'll do it too.

  • You're the first one to mention code reviews and just earned a +1 for - Being forced to defend the mess you did to the code base in public can be very educational. Code Reviews, however, rely on someone on the management level to really care, and if that someone is missing, you are doomed IMHO. – tofro Nov 19 '16 at 11:54
  • @tofro: thank you. However, code review is only one of the aspects. Automated style checking is ways more important, but wasn't mentioned in any of the previous answers. Metrics weren't mentioned either. Similarly, none highlighted the fact that the OP calls his code a “piece of art,” although this is a very important aspect. – Arseni Mourzenko Nov 19 '16 at 16:32
  • @tofro: “Code Reviews, however, rely on someone on the management level to really care, and if that someone is missing, you are doomed”: according to my experience, support from management is not a prerequisite. I had to work in teams where management was actually hostile to code reviews, considering them a waste of time. We were still doing them and it brought measurable benefit in terms of code quality (less bugs and less time solving bugs), and a non-measurable benefits of happiness and experience of team members. A good team can do great things, even against incompetent management. – Arseni Mourzenko Nov 19 '16 at 16:37
  • I do agree you don't need management support when the team has a common interest to go with CR - apparently, this isn't the case here, though. – tofro Nov 19 '16 at 17:55
0

Implement coding standards and stick by them, design patterns, code snippets library that one can use as guidelines, etc.

Coding standards can range from deciding if to use spaces or tabs, what design patterns to try and use, naming conventions, etc. This will go a long way even if everyone codes differently.

0

If you can, implement coding standards and code reviews--to start off review every single checkin. With a small team it will be a hard sell to people who don't understand that spending an extra 2x or 3x on your code up front will save you 20x or 30x on the overall development time, but that's another concept that is worth getting buy-in on.

I wouldn't try to implement everything at once, and I'd try my best to get them to come up with standards as well--not just indentation but try to get them to think about things they have encountered in their code that have made their lives easier or harder.

Consider having a meeting one day a week for reviews of what went right or wrong for each person during that week--you might also offer a chance for each person to say what someone else did that was most helpful that week--stuff like that. You could look at XP/Agile books for more ideas like this. Being a small team, again, this could be a hard sell.

You mentioned language issues. If these workers are local (Either on-site contractors or full-time hires) that shouldn't be too much of a problem but if they are overseas contractors working remotely--let me just say that in my personal experience this is not ever going to be fixed, either ride it out until management figures out that it won't work or consider leaving the company. Do not get into a situation where you are responsible for their work, and do not waste time trying to fix the team's development practices. Most likely your job will evolve into spending 100% of your time making their code work. Many overseas contractors are great programmers, by the way, I'm just referring to the case where the contracting company sent you the type of talent that you described.

0

The symptoms that you describe strongly suggest a lack of team cohesion.

In such situation, coding standards, training, procedures or tools will not be the silver bullet that could improve substantially the quality. You first have to develop a team spirit, open and constructive communication and a shared ownership of the product.

Symptoms :

  • "they just do what's required and go home": sound they are demotivated. Weren't they more enthusiastic when they arrived ?
  • "they" against "us"/"me"/"I" : lack of mutual trust ?
  • "I gave some tips: I commented PR on Git" : the tone of written criticism is sometimes misinterpreted as aggressive or arrogant despite constructive intention. Why not discuss it face to face ?

You are a small team : use this advantage ! Some ideas to start:

  • Make important decisions collectively. Discuss openly disagreement. "Discuss" is not to impose one view point, but to listen and try to find a common ground.
  • You've refactored important parts of the code, so you have a really strong ownership. Let them buy in. Let them have a word to say.
  • And for very sensitive but highly subjective topics like code formatting, just outsource the duty to an automated pretty printer that will reformat according to standard and without feeling at each check-in.

Quote of the day:

If you want to go fast, go alone. If you want to go far, go together

0

Your question can be answered by "Change your company or change your company". For those who don't know, this means that you stay and fight to bring the change you want to see in your company, or change the company you work for (i.e. leave and work some place else).

The second part is the simplest. You leave and find a company that shares the same values you work by. The first is not so simple because of... people.

What you need to do is change people. Thinking that they are broken and you need to fix them is not going to work. People are emotional beings. This can easily degenerate in personal wars. So...

First of all, you need to find out why the situation is the way it is. Talk to everyone. Find out. What you see now is the result of decisions taken throughout years (or maybe not taking some important decisions at the right time). Don't judge and don't jump to conclusions.

Was this caused by inexperienced developers? Was it caused by management trying to reduce costs by hiring cheap graduates instead of more experienced and expensive developers? Is this about people being lazy and ill intentioned or people defeated by a broken system? Are deadlines forcing you to do "what must be done" to get it working or people just waste their time and don't care too much on what they are working on? etc.

The problem with this field of software development is that people learn on the job. If they work in a crappy environment, they will pick up bad habits. And habits tend to stick and be hard to shake. Then they don't know better because that is all that they know. Not all developers are passionate about what they do to invest time in getting better or seeking to improve. Some got into this business for various other reasons. So find out why people are how they are.

Then there is management. Is management unaware of the situation or just doesn't care? Find out. You absolutely need to have the support of management if you want to improve things. If something that took 3 months to build all of a sudden starts to take 4 months because you now need to write tests, do code reviews, discuss at the whiteboard with the team to decide on good solutions, pair program, etc, you can be sure that management will notice the time difference. Something that changes from 3 to 4 months is easy to observe and measure. Having a solid code base, a maintainable product, good stable architecture, stuff that makes for a better product structure is not so easy to measure. How much time the best practices buy you on the long term cannot be measured upfront, maybe not even after the fact. On the other hand, a one month delay is a no brainer. So have management support on this. Prepare to make a hard sale.

Also look at the context of the business. Is this affecting the way you work? Do you have opportunities that must be followed at any cost, including sacrificing quality of code or best practices?

Let's change perspective for a moment.

I feel very upset when they add their spaghetti to my piece of art and it affects my mood at work and my productivity.

Sorry... your what? Art? I know most of us are here for the recognition from our peers and you only get that if you are a good developer, but is your code displayed in a museum next to a painting? Does it have to cause emotions in the people looking at it? Tears of joy and bliss? Yes, I'm sarcastic and I'm deliberately exaggerating because I want to say to keep a sense of reality. Don't get emotionally attached to your code.

I used to work with a guy that would happily throw the team, project and company under the bus just to impose his "art" on everyone. He was the "truth holder" and, by definition, everyone was just inexperienced, blind, unwilling to learn, didn't care, or just plain stupid. Don't become that guy. As a software developer your job is to write good code, tested code, maintainable code, code that adds business value and can continue to do so under constant future changes. And you have to do all of that under budget and time constraints. That's what it means to be a professional software developer. Unless you're an art gallery, art is bad for business. Be pragmatic and keep a balanced view on things. "How to ignore bad code my coworkers write and just focus on work" got your question closed because of the way you framed the problem. Step back and look at the whole thing.

How can I address this situation without just focusing on 'bad company culture', 'inexperienced graduates', etc. and actually start to improve the situation.

TL;DR: Carefully look at the situation to find out why things ended up in that situation. Accept that the situation is like that and see how you can improve from there. Find out what everyone's opinion is on this. Pick your battles. Forcing change doesn't work. Collaborate to make the changes. You should try to show how things can be improved not point out how bad they are. Convince everyone that what you want to do is for the greater good on the long term. Get them on board.

And do it in small steps.

If you bring too much of a change all at once people will feel discouraged and give up. Changes take time. Change your company or change your company. Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.