I’ve been programming for 20 years now, doing commercial work for the last 8.
Over the years I’ve been exposed to different ideas and experiences that have constantly affected the way I work.
What matters and how I go about working for my clients?
Over last 3 years I’ve been mostly tasked with hands-on lead roles, my goals were to deliver project on time and with good quality.
Mindset - Put yourself in your clients shoes
Whenever working on a project I like to think about it as my own project, I try to understand not only technical aspects of the project but also its business goals.
Care deeply and it's easier to deliver quality work, avoiding shortcuts and making sure the client will succeed, and if they succeed then they’ll probably come back to you. It’s a win-win.
Establishing consistency when joining new teams
Whenever I join new team, I like to know if there are any established convention for code style, quality and similar.
If there aren’t, I share my guidelines and process description and ask the rest of the team to read it and then have a discussion if they agree with it or we should adjust some things.
One has to remember that code style is subjective and there usually isn’t a right or wrong answer, what matters, though, is consistency.
I’ve no problem using someone else's code style but I wouldn’t want to work on a project that has inconsistent style / approach to coding as this is a sign of low quality.
It’s important to learn your team-members strong and weak sides and get to know them as people, not just developers.
Code Quality
Quality is something I’m not really willing to negotiate on, I want the projects I work on to at least have:
- -Weverything - enable all warnings as default, disable some selectively
- Treat warnings as errors - there are proper reasons warnings exist
- Add Guards for UIKit/CoreData + threading
- Scripts that will raise developer attention for TODO/s and code smells
I would also prefer to have BDD tests in the project. I prefer BDD over TDD as it’s more focused on what matters for the client, I will use TDD when working on a library or some reusable part of the app but keep BDD for more general code.
Many people think tests make you slower, but even if we put long-term effects of quality aside (tests are definitely worth it in long run) you can also see that tests can actually allow you to iterate quickly:
- If you are blocked by lack of API endpoints you can mock your data and still implement your part of the logic
- Executing tests is usually much faster than running whole app and navigating to specific feature, I can adjust and run few iterations of tests in the time it would take me to just launch the whole app once
- Regression testing - afraid of refactoring ? never again
Remember to use Continuous integration if you do testing, be it Jenkins or Xcode bots. I don’t trust developers to always run tests (including myself).
Refactoring
I constantly refactor my code, I don’t allocate time for doing it, I just do it every time I see something is not correct.
If your IDE makes it hard to refactor your code, upgrade your IDE. I’ve been using AppCode and Xcode with same project opened in parallel for last 3 years.
Coordinating work with other developers
When it comes to version control, I prefer git with git-flow approach to branching, git-flow is mature and is becoming industry standard.
I also like to leverage the fact that you can integrate JIRA/Bitbucket/Github together:
- naming your branches same as tasks in JIRA will make them clickable links
- commit messages can close or reference tasks
Automating this kind of tasks will improve efficiency and make it much easier to find references if needed, e.g. When you need to reverse a feature, find it in jira and then you get commit hash that created it.
I like to have at least 2 developers on every project, even if part-time, as this will avoid situations when a person needs to take vacation or leaves the company and the whole project has to stall or we need to bring in a new developer up to date before we start making progress again.
There is no this is my code or I didn’t write this, team-work and shared codebases, it doesn’t matter who wrote code that has bugs, everyone makes mistakes and it’s the team’s responsibility to fix them.
I prefer to avoid assigning particular roles for a developer:
- e.g. Michael does UI and Matt does the Model
I’d like to see Michael leading the harder UI Work with Matt pairing with him and vice versa on model stuff, simpler parts would be split so that each of them can work on both model and UI.
This again will prevent stalling situations but it will also allow developers to learn more from each other, allowing them to grow their expertise and thus increase their value.
I also believe good developers enjoy learning new stuff and they grow impatient and resentful if they can’t, so by allowing them to learn more we will limit rotation (leaving) in company.
CocoaPods or Submodules ?
I love CocoaPods, but I sometimes use submodules as well (e.g. Swift code right now doesn’t work with CocoaPods).
Either one will work, whatever you decide, make sure you use them correctly.
If you use CocoaPods, then commit them to repository. If you use submodules then I’d like to have them forked. Why?
Version control is meant to keep working project across the history, if I’ll want to run foldify code 10 years from now I want it to work by just pulling from repo.
If we don’t commit pods this might happen (or have happened before):
- CocoaPods repository goes down -> can’t work
- New OSX version have issue with CocoaPods gem -> can’t work
- Someone removes their git project and you can’t install it anymore -> oh, I guess you won’t get much sleep tonight
- You got access to a project but not to private cocoapods that the project used? -> can’t work
- CI build has a bug that your developers can’t reproduce? -> I guess you were using :head and didn’t commit pods.
Similar issues might happen with submodules.
If you commit pods, all of the above will go away.
Code reviews
I don’t care if you are ex-apple, twitter, Facebook or any other kind of self-established genius, everyone makes mistakes, myself included.
Code reviews are helpful in finding avoidable bugs before they reach your client.
I like to have peer code reviews, and it has few advantages over only team leads doing it:
- Shared knowledge of code base, since usually few developers work on a project I would like to see everyone knowing they way around the code base.
- Bottleneck and avoiding quick approvals. There is only limited amount of work one can do, having one or two person responsible for Code Review makes them bottleneck for whole team + people under stress will compromise quality of the review.
Keeping branches and code reviews small is crucial, I always give this imaginary example:
- If you give a developer 100 lines of code to review they will find 10 bugs.
- How many bugs will they find in 1000 lines of code? 10
Too much code to read or review is overwhelming for most developers because of limited working memory capacity, keep it small so people can focus.
Big advice when it comes to Code reviews:
Don't take it personally if someone critiques code that you wrote, they are critiquing code and not you as a person.
I like when people challenge my code because I can learn from their experience and improve it.
What do I do when I have free time?
There are high and low times in every project, sometimes we are blocked waiting for someone else to deliver their part , etc.
What I like to do is try during that time is to either (ordered by preference):
- Find ways to help improve company efficiency, often by creating tools and libraries to help solve common issues:
- Share my experience with other developers and teams, I often speak at public conferences but I also do Lunch & Learn sessions for my employers
- Research new technologies that we could use in future projects
Conclusion
I didn’t use to do some of those things when I was starting out.
Some of the things I did were exactly the opposite of what I do now, we constantly learn from our own mistakes.
I’d love to hear how does your process and mindset look like, especially if it’s very different from mine!
