How/where can I get external feedback for improving programming style and general work habits?

Question

Problem

I am a software developer and have been told by more than one employer that I do my work too slowly and make things more complicated than they have to be, and I have to change this as soon as possible but am having a hard time doing it alone.

Background

I've got a mixture of academic and professional experience with programming: A university degree and a couple of years' work experience at various companies. I've been told more than once that I know what I'm talking about, so they don't think I'm entirely incompetent. However, it's very apparent that I've developed some very bad programming practices (at least from the eyes of the employer) and I need to correct these as soon as possible: Everywhere I've worked, a programming solution involving a lot of small classes, inheriting and/or delegating common behaviour, etc. is seen as bad code. Some may think this to be clever, but it's not... because all this "cleverness" can/will lose me my job.

Question

How/where can one best get explicit feedback on how to improve one's style/working habits? -- I need active feedback on what I'm concretely doing wrong, not just what I "should" be doing: e.g. reading books don't seem to help-- If anything, they often seem (to me) to support my existing bad habits: For example, in order to complete a specific (one-off) job, I took similar code from another job and put it into a common abstract class. Another guy found a bug in my code while working on the problem together and then asked my why I made everything so complicated for a one-off job... but, in my eyes, it wasn't a one-off job because they were so similar and the same code could be re-used for even more jobs. Despite how this sounds, I am not the one who is right here: Those who criticise me always have significantly more experience than me, so, either all experienced programmers are bad or I am a bad programmer.

Answer 1

Did you ask those who complained about the way your code was structured about how they themselves would have structured it? You might as well look for mentors where you can find them - that is, right among your critics.

Anyone who criticizes your work should be made to pay a price, the price being that you get to pick their brains. They would have to tell you how they would have done it. They would also have to tell you how they managed to learn the programming practices that you are not familiar with, and what references to hunt down.

When you don't know what the enemy is up to, either you go crazy guessing, or you send out patrols to snatch prisoners and ask the prisoners. You need to snatch as many of your critics as you can and pick their brains.

And of course, you want their feedback on an early and continuing basis. Emphasize that you know how to code but you want to structure your code the way they want it, which is why you are coming back to them on a regular basis to make sure that you are on the right track. You don't want to wait until you are totally finished before you solicit their feedback.

I wouldn't be surprised if different places have different programming practices, so stay on your toes and keep the lines of communication open.

Answer 2

so either all experienced programmers are bad, or I am a bad programmer

Sounds like maybe you're being too hard on yourself: It's by no means so cut and dry. Every programming task can be attacked in many ways, and most of the time there isn't one "right way". It's a question of trade-offs, and the ability to judge such things has a lot more to do with experience than raw programming skills and talent. Knowing when to "go by the book", something you appear to be good at, as opposed to solving a given problem in the real world work context, is gained only through experience. That's the reason why experience is always stressed in job descriptions for programming positions, and in general.

So, even if the experienced programmers you're dealing with are very good, you might also might be an excellent, talented programmer, but simply lacking the required experience and exposure required to correctly and practically solve real-world problems.

As for ways to move forward, @VietnhiPhuvan's answer is excellent. Another thing you can do, which is often possible even when you can't easily "pick someone's brain", is to look at the code of those who are claiming they know better. If you've done something that others complained about, look around in the code base for similar problems that others have solved differently: If you understand how and why they are better than your solution, learn from that code. If you think not, if you have a decent working relationship with your peers and seniors, take out the code example and gently ask why they handled something in a particular way when there were alternatives X and Y also available. You can learn a great deal from such exchanges. Sometimes you'll learn that @Telastyn's comment was very applicable to your situation and the people criticizing you aren't really very good themselves, but just as often you'll get some new insights, and advance your own knowledge and judgment.

Answer 3

Developing good style is hard. This is partly because it is a balance between often competing goals, partly because it requires creativity, partly because code clarity is subjective, and partly because it depends on a lot of context. For instance, good style in an open-source project is different to good style in a startup which is different to good style in corporate software, even if the software does the same thing.

Put another way, there is no "recipe" for good style. It is something you constantly improve and refine and adapt. So, how do you improve your style?

• Practice. Write code. Experiment with stylistic choices. Read other people's code and see what you find the easiest to understand, change, etc.
• Code reviews. Throw up some code, and listen to what people say on what's easy to follow and what isn't, and how they would have done it. You'll also learn by going to other people's code reviews.
• Reflection. Write a blog (or diary, or vlog, etc.) where you discuss style. Talk about what you've learned, and give examples. Reflection and teaching others are incredibly powerful tools for your own learning. Contributing to Q&A sites counts although it's good to have a blog as it encourages you to look back on what you've been doing recently and see what you can draw from it.
• Reading. Read (and watch) as widely as you can. Read textbooks, blogs, Q&A sites, style guides and source code from various places. Watch talks, and go to some if you can.
• Learning. Since good style is largely about communicating with others, learn anything that will help you communicate. Learn about personality types, and try to pick your colleagues. Learn about teaching and learning. Learn another spoken language! Learn negotiation techniques. Good style is also about writing code that has a minimum of bugs - so learn about different approaches to achieving that (for instance, learning about formal methods and functional languages has affected the way I code). Good style is also about doing more with less code, writing more maintainable code, and so on, so again, learn all you can about different ways of achieving these things.

But there are some things that should be pointed out:

• Sometimes the "theoretically" good way to write code isn't actually all that good in practice. The more you abstract away behaviour, the more effort it is to pick up a piece of code and figure it out or fix a bug, particularly for someone who doesn't work with that code very often. Yes there are often benefits to abstraction, e.g. only having to fix a bug once rather than fifty places. But sometimes less abstraction is a good choice.
• You do need to take into account who is likely to look at the code, and whether they're going to have time to become familiar with it or whether they're going to want to go in and make a quick fix.
• That doesn't mean that you must avoid anything that your colleagues don't understand or don't like. But perhaps only use such techniques when you think there is a significant advantage, and justify this to your colleagues - hopefully they will learn something.
• Some developers are lazy and prefer to write code in a style that's doesn't require much thinking or effort, even though it requires more time in the long run, because they will be paid for it anyhow.
• That said, a professional developer (particularly a senior developer) should work in a way that's best for the business, which means writing high quality code. You're not a senior developer, and working against all your colleagues is not likely to be a good idea, but maybe you can make a strong case for certain changes in practice that will result in better code quality. Ideally you would be rewarded for this (it's in a business' interest to do so!), but we don't live in a perfect world.

Answer 4

I agree with Vietnhi Phuvan (good answer), and I would say that this all boils down to communication. You need to clearly state your plans up front to an architect or more experienced programmer on your job, and be prepared to answer as many questions as the architect has.

Sometimes when I see lots of small objects it's because the writer doesn't understand how to use the built-in objects and functions of the language, so this may be a sign that you need to buckle down and truck through the language documentation.

To generalize this answer to all knowledge work fields: communicate about your plans with a more senior knowledge worker at your firm early on in your project, and take their advice under strong consideration (or just do it their way, if they're your boss). Take the time to really understand the technology and structure of the space you're working in, and don't just apply more complicated and generalized structure you've learned from books and instructors unless you have very good reasons to do so.

Answer 5

There's a very useful principle, KISS

Keep It Simple Stupid

Never make anything more complicated than it needs to be.

If something might be re-used in the future, that doesn't mean you write the re-use now. Write what you need now for the features you need now.

Of course that doesn't mean you don't think of the future. This is where the tricky balance comes in. Do not write in ways that will prevent re-use in the future, but at the same time do not try and think ahead of time of all possible future requirements.

I can almost guarantee that the future requirements when they come will not match your flexible class and you will end up needing to change it anyway.

So this is why simplicity is key. The class should be simple, and easy to understand, and easy to refactor in the future as more requirements are known.

Once you realise that no matter what you do your code will need to be refactored in the future then it becomes clearer what you need to do. All the properties of good behaviour like loose coupling, easy understanding, single responsibilities, etc are about making it simpler and safer to do that refactoring. Making an all-singing-all-dancing class will end up with you building a lot of features that are not needed and at the same time not providing the one feature that it turns out is actually needed.

Answer 6

First of all what other people said is right--Just because a programmer has been around a while doesn't mean he has any clue what he's talking about. I had a team lead once tell me not to use the ?: operator in Java because "Nobody knows what that means".

In a way, however, he's right. If the rest of my team is going to take more time pulling apart one line of code than an if statement, the if statement is the "correct" way to go. They both make the machine work the same.

Also your field matters. In an enterprise situation your strongest focus should be on making your code readable, but in many other areas (Small teams/startups?) perhaps being able to write code quickly is more important.

So to address some of your specific issues:

Class size--Smaller is probably more maintainable. Period. You're good here.

Try to do your best to avoid inheritence--I realize it's tough but it really does lead to confusing code. If you want to use code, try to use delegation wherever possible, leave inheritance for cases where it's really obvious that it is exactly what you need.

Speed is one I struggle with. I take more time but often find that my code has less hitches in QA and later (Which tends to be more expensive to fix). Try following a small project through it's lifecycle and see how little of it is actually related to coding. Many people forget this. (Again, this can depend on your situation)

Overall I'd say you probably have good instincts--the most important of which is to have an open mind and learn. It seems like every few years I'm picking up some technique that helps me code better--there is no book you can read to become an instant master--most is going to be learned through trial and error.

One technique I can suggest: Be sure to examine old code you wrote every time you come across it with a critical eye--regardless if it's the next day or a year later. If you have trouble reading it, add comments and try to understand what you could have done better. If another developer doesn't understand your code, redo it (Chances are if someone doesn't understand it, you won't understand it either in 6 months--cute tricks are like that).