Another engineer asked me for feedback...

Another engineer asked me for feedback on their performance. I wrote a few things down and then re-read it and realized this could apply to almost anyone. What follows is the advice I gave them. Names and technologies have been changed for their own protection...

What am I doing wrong?

I tend to think positively, which means I can’t tell you what you're doing "wrong" necessarily, but I can tell you some things I’d like you to look at and think about as you work on our application. These are just things I’ve noticed that I think could help make you an even better software engineer.

I know you’ve been writing code for X years, but always be learning!

Where we're going, we don't need ROADS...

Think about the future of the code you’re writing. Don’t just go with the first idea that you have! The worst way to write code is to sit down and start writing and trying to get it done as fast as possible. Think about what the simplest solution would be, and try to implement that. Here are a few things that help me:

1) Be open to refactoring.

2) How can we make sure another engineer (especially an inexperienced one) will understand it, even years from now?

3) What is the least you could do? This isn't 'Code Golf' where the person with the lowest number of changes or lines of code wins, rather it's deciding "what is the easiest solution that will satisfy the requirements to the current problem, but doesn't add technical debt to be fixed later?"

Study (and do it on company time, too!)

Study everyone’s code and every pull request. You have a little bit of a disadvantage coming from X years of Technology J into a Technology K environment. Things that are written a certain way in Tech J are very different in Tech K.

Take a look at our primary programming paradigm. It’s what we TRY to do, and we fail at it.... a lot. Our code tends to be more Functional in the front-end, but we tend to mix in more Object Oriented concepts in the back-end (which you're probably familiar with from Tech J). We use all three paradigms in the application, and it's best to understand them all. I promise you, in the real world you will find and write Procedural code. You might not realize it, and something or someone might even tell you that you should feel bad for doing it, but if you understand why you use each paradigm, and can justify your code, then there's no problem (usually)!

Be familiar with modular code and separation of concerns. We want to make sure that we don’t introduce dependencies between parents and children. Sometimes it’s unavoidable, but we tend to try and avoid it (If it's going to take three days to add that next level of abstraction, the cost/benefit might not be there!). We want every front-end component and every back-end service to be able to live on its own anywhere, inside or out of the application.

Be innovative. I know it seems like I’m trying to get you to write code in a certain way (and in some cases I am!) but if you see a better way to do something, bring it up! If you want to talk about something, send us an email, schedule a meeting or catch us when we’re all online at the same time. Be open to the fact that we MIGHT not use your suggestion, but know that it’s appreciated!

Teamwork Makes the Dream Work

Study some more! We’re using some older frameworks, so it might be harder to make sure you’re using the right online resources. Ask your co-workers if there’s something you don’t understand or you think there might be a better way. If you work near to each other, try out ideas on them before you put it in the code (They should do this with you, too).

Our QA Engineer and I Skype each-other all day long. Even though he doesn’t write a lot of application code, he helps me to talk out a solution before I try and implement it, so I can avoid realizing after three or four hours of work that my solution might have an odd edge-case, and it helps him to understand my thinking when he goes to test it.

Check Yourself Before You Wreck... nothing, because that's what source control is for.

Depend on your teammates (me included) and question everything (especially the code you write). Make sure that you have reviewed and tested your code more than anyone else, and code-review your own code immediately after you open a Pull Request. It can help you to put clarifying comments where you think we might have questions AND I have caught more bugs than I can count in my own work by code reviewing it myself! If you don’t think you would have understood the code when you first started as a developer, then it might be worth looking at for a refactor. I refactor my code many times before I say it’s done.

But this one goes up to 11... OR They've Gone PLAID

Speed is not the goal, it’s the result. When I was in the Army we had a saying: "Slow is smooth and smooth is fast". It means that if you take your time, practice, and make sure that you do something the right way every time, eventually it will become an easy thing to do. Once it becomes easy to do it the right way every time, then you will automatically get faster at it.

The same applies for writing code. Don’t try and rush to get to the end of a story just so you can say you finished it. That will cause a lot of code review, bugs might be found and you’ll end up doing rewrites. Take your time to make sure it’s right and test it over and over again. Question your solution over and over again, as you write it and before you say it’s done. That way, when it goes to code review and testing it will fly right through.

Code Review: It's What's for Breakfast... Lunch... and Dinner

Last note: Code review! I want you (and everyone else in the team!) to be more active in code review. One of the most important things to know about this team is that no one "owns" the code. The TEAM owns the code.

If you tell me you see a problem with my code, I will discuss it with you. If you don’t understand the context of my code, I’ll see if I can simplify it. If you think another engineer could have written a better variable name, or a simpler function, tell them, and don’t feel like anyone will be offended or upset by your comments!

Code review is the time for the whole team to make what one developer wrote better before it goes into production, and no one writes perfect code!

Insert Agile framework name here's biggest benefit is that it brings conflict to the surface so we can address it early. Conflict doesn’t mean we get angry at each other, it just means we can discuss differing opinions to make the code better. I don’t mind having different opinions. Occasionally we won’t agree, and that’s why we bring the whole team to the issue. Because everything we do in the code is a team effort! Without a team, we're each just individual developers, trying to write more code than we have time for, and probably creating more technical debt than we could ever fix.

If you don't know who Martin Fowler is, find out. Design patterns and Code smells are good to know, but don't memorize them. Knowing they exist, and where to look them up will serve you well.

If you don't know who Fred Brooks is, find out. "The Mythical Man Month" may not apply as much to the average software development team of today, but the lessons he learned in the 1970's are just as relevant today.