8th Light is a consulting firm that teaches people how to write high quality software. They offer a service called Embedded Coaching. This involves joining a company’s team and teaching best coding practices through that company’s code. Dave Moore, the Director of their LA office, has always been obsessed with learning about software, so it makes sense that it’s his turn to teach it.
Learning from Writing Poor Quality Code
As a small child Dave Moore was into video games and wanted to be a part of that world. In high school he took on every class about software that he could. He completed each computer science class by the end of his sophomore year and even finished with college credit. So during his junior year, he started a work study program in software development for a small company. He worked on software architecture and java programming during this time. It later turned into a full time job. During this time he was also competing at the national level for Java programming and software architecture. The thing about this job though, is they never set best practices in place for creating high quality software. They just wrote code that was good enough. But if other people needed to change that code, they wouldn’t be able to. And no one told Dave any different. So he quit writing software and studied marketing in college. But jobs weren’t as promising in that field coming out of school. So Dave fell back to what he knew and started his own software company.
Dave’s company built websites similar to weebly or squarespace before weebly or squarespace existed. They hired an offshore consulting company to help. And again, they built a poor system. It was the blind leading the blind. He was working long hours to make up for having low quality development. He knew there had to be a better way to go about this. That’s when he found 8th Light and joined as an apprentice. Dave was mentored by one of the co-founders, Micah Martin. What he really learned is that quality matters. Micah taught him how to create quality software where the output means you have a system that is fully scalable and allows for inexpensive adaptability. Micah, is heavily interested in Japanese Martial Arts and would often mention a famous japanese proverb about the rainbow. There are seven colors in the rainbow, but according to the proverb, there is also an 8th that can be felt but not seen. This is similar to well crafted software. You can feel if something is operating smoothly but you can’t actually see the code. At this point, Dave has had so much experience writing bad code and great code that he can easily pinpoint the difference between the two.
The Benefits of Learning Backend from a Mentor or Apprenticeship
The father of Dave’s mentor, Micah, is Robert Martin. A pretty well known author. His most famous book is titled Clean Code. The apprenticeship program that Dave went through with 8th Light, is based around this book. The mantra of the apprenticeship program is that software is not written for the benefit of any company, in fact it’s deleted when you’re done with it. So, Dave was told to write a program and then delete it. He then had to create the software again with different constraints. This protocol helps put apprentices in the mindset that there are more ways than one to solve a problem. There’s also merits for each approach that affect the attributes of the software upon completion. For instance, Dave would write code that works and feels great and then be told to delete it and write it again. But this time, Micah would not allow Dave to use if statements. This forced Dave to look at building code in a different way. He was able to find methods he didn’t know were possible. It helped him incorporate all of these methods into one build. He learned how different parts of one application can be cleaner by taking a different approach in each section.
Oftentimes, Dave would have to write an automated test before he even wrote the code for a project. This would force Dave to allow the test to dictate the structure of the code. Dave’s example is “if you want a circle to be blue, before writing code that makes a blue circle, in the test you would write an expectation for code that creates a blue circle. And then you would run the test and it would fail because you haven’t written that code yet. But then, of course you would go back and write the code and run the test again and it would pass.” Test driven development, where you let the tests drive the architecture of the code, allows you to write a use case where it’s using the actual code. You’re highlighting how easy the application is for users to use every time you’re writing a line of code. It takes a disciplined approach, but by the end you will have an extremely easy to use, highly decoupled system. It will also be easy to track the state of the application from start to finish.
What Renders the Title of “High Quality Code”
According to Dave, great code is fully scalable. He leverages the scalability by looking at the RPS or seeing how many people can use the system at the same exact time. To do this, it requires a knowledge of functional data structures, as well as decomposition of extractions and architecture. This way he can create more servers that host a particular part of the application automatically. Dave also strives to have inexpensive adaptability. He makes sure features are well named and that they’re easy to add on to. He makes a note for editing purposes if edits need to be made in one place or multiple places. He always keeps in mind the future of the software, meaning if someone had to come back in and make changes it would be easy for them to do. No more quick builds that are “good enough” in the moment. Great software always makes room for easy improvements.
Keeping Software Fun
Passion is one of the main aspects of writing good code. The passion to always be better. And to make sure writing software is fun. There’s a lot of ways to tinker with software to make it fun. To incorporate more fun, Dave automated parts of his house. He created a system in his house to water his plants for him. All he has to do is make sure water is available. The system automatically checks the moisture of the soil every two hours. If the plants need water, the valve from the water jug opens up and waters the plants. This is code for no one but himself. Keeping it a hobby as well, puts the fun back into the process.
Dave also enjoys learning from speakers at conferences on what they claim to be clean code. He is always wanting to know more and asking questions of how his code writing can be improved.
The Importance of Creating Group Mind
Well crafted software is about creating inexpensive adaptability. But software craftsmanship is about creating a culture where you are developing fertile ground to build well crafted software. Making sure your team is just as excited about writing software as you are is very important. Because if not everyone is excited, the code you write together most likely isn’t going to be high quality. It’s about creating a like mindset with your team. A lot of clients that 8th Light works with, very much treat the creation process as a 9-5, clock in-clock out environment. Investing in the team provides benefits to the creation of code as well. Things like watching a conference talk together for an hour, or starting a book club, helps to put everyone on the same page. If a support system isn’t put in place for the team by the company itself, then as a result, the software created by that company will be of lower quality.
Common Mistakes In Software Development
The steps most often missed are during the process of creating the software. It’s about collaborating. It’s important to institute a range of collaborative efforts like pairing, using whiteboards and gathering the team to hammer thoughts our visually, self organizing teams to solve particular problems, and many other avenues. It’s a balancing act of meetings and coding in between. A reference to help institute a more collaborative process for yourself is the Agile manifesto. Dave also recommends reading original outputs from those who wrote the manifesto. They were very experienced developers who formed the Agile methodology. It will give a better understanding of what writing software in the Agile style will look like.
What Makes a Great Backend Developer
Passion and process. One of Dave’s current developers actually wrote his own article about this very subject titled “How I used Scrum to Teach Myself Software Engineering”. This developer, Ian Carroll, had zero knowledge about writing software. But he knew a little bit about the scrum process, which is in the Agile realm. So he applied this process to versioning his understanding of writing software. Every week he was getting better and tweaking his process based off of his previous week’s performance.
What Creates Strong Backend?
Making sure everything is well tested in an automated fashion to verify correctness. So if you don’t have a system of automated tests, create it. Also, having systems in place, where at a glance you understand what they do. Dave wants to look at an applications main file, read for about 5 minutes, and walk away with an understanding of how it functions. If he can’t do that, and has to jump around from file to file then there’s a problem. Intent needs to be obvious.
Carefully Changing Bad Code
Sometimes it can be simplest to just rewrite the application. Almost always that is not the answer though. It can be hard to work with rewriting old software and getting it right. The thing about software that works is that it has scar tissue. Since it is legacy software, typically the right thing to do is slowly refactor the old software system. A good exercise to get you refactoring an old system that doesn’t quite make sense, is by going through the Gilded Rose Kata. This is an exercise that gives you incomprehensible code and your task is to add a new item with different attributes. It’s your job to go about doing that without breaking any of the existing code. Dave suggests not just doing the exercise once, but trying it 5 different ways. It gives you the luxury to experiment with no time limit.
Practices That Make Perfect
Reading is another helpful practice that Dave relies on. When creating software, Dave suggests “Have fun and read books.” Here is a list of his favorites: Enjoy!
The Passionate Programmer by Chad Fowler
Clean Code by Robert Martin
eXtreme Programming Explained by Kent Beck
Working Effectively With Legacy Code by Michael Feathers
The Pragmatic Programmer by Andy Hunt and Dave Thomas
GOOS by Steve Freeman and Nat Pryce
Release It! By Michael Nygard
Domain Driven Design by Eric Evans