14 rules programmers should live by
on 22 January 2019 for ProfessionalsHave you heard the urban legend about the 10x developer? You know, the superstar developer who accomplishes ten times more than any other programmer on their team? It’s a fairly controversial topic with people on both sides. Some state disbelief while others claim that true rockstar devs are 100x more productive than their peers.
Well, whether the 10x developer is a workplace myth or a fact of life, there are some truly great programmers out there. So, what sets them apart? All successful programmers live by certain rules that help them achieve greatness. If you’re a programmer, applying these rules can help you become more efficient and productive. So without further ado, here are 14 rules that all programmers should live by.
Rule #1. Begin with the end in mind
Always get the customer or the management to sign off on a final design long before you even touch a keyboard. This sounds like a no-brainer, but a surprising number of programmers neglect this important rule. Many popular agile software development methodologies such as eXtreme Programming (XP) or Scrum have a fair amount of overlap and this can produce never-ending programming endeavors if you aren’t careful. Getting a sign-off before you start is a nice insurance policy against work that wasn’t necessary in the first place.
Rule #2. “Move fast and break things.”
This legendary Silicon Valley mantra is a rule to live by throughout your programming career. In simple terms, it means focusing on progress, not perfection, and not letting the limits of your knowledge stand as barriers to success. The best programmers realize that code is cheap and think nothing of scrapping hundreds of lines to start again from scratch with a different approach. Learn to think of deleted code as a learning output, just like shippable code. It’s part of the process that will ultimately lead to the right result.
If you’re just starting out, treat your mistakes as learnable moments, not failures. This process is critical to your professional growth. If you’re looking to level up, learn to recognize when a certain approach isn’t working and when you’ve given it a solid attempt but need to start afresh and approach it from a different angle.
Rule #3. Move fast, but not too fast … consider architecture first
Too many programmers start coding before thinking about architecture. This often leads to big problems down the line. Just like making a plan to achieve your dreams, you need to consider architecture before you begin writing the first line of code. Consider what the code will be doing, how it will be doing it and what will use it. Which modules and services will have to work with each other? What structure should the code have? How will you test, debug and update it? Only once you’ve considered these things should you start coding.
Rule #4. Understand the roles of each team member
In an effective team, each member will fully understand their own role and set of responsibilities. Everyone on the team should be on the same page. That way, if someone wants to change roles or work on a different piece of code, they can find the person responsible.
This approach works wonders when it comes to code review. If you have a developer who understands over 90% of the code and can simply monitor the updates, that’s fine. But if you’ve got different team members reviewing different parts of the code, the risk of errors increases dramatically. This is especially true if your team uses code review as a way of teaching new members. You need to be clear about everyone’s role from the outset to avoid mistakes in very hard logic during the project.
Rule #5. Always take responsibility for your mistakes
When Mark Zuckerberg coded Facebook, he likely never imagined one day having to endure ten hours of questioning by Congress about his company’s privacy practices. His immediate, unreserved apology was a masterclass in applying the fifth rule on our list; always take responsibility for your mistakes. We’re gonna let you be the judge of whether or not Facebook has bettered itself since.
True rockstar developers accept that mistakes happen, especially when working on a team. They realize that these mistakes may not even be directly related to the code itself. They could stem from miscommunication, business decisions or processes beyond anyone’s control. Never try to pass the blame, just accept responsibility and move on.
Rule #6. Take shortcuts when necessary
One of the hardest skills to learn is being capable of writing bad code. Programmers have a tendency to live in absolutes – especially when they are young and idealistic – but the real world is messy and sometimes you can’t avoid turning in code that is less than perfect. Don’t be afraid to take a shortcut when necessary. You can’t always be perfect and there’s no shame in becoming a Duct Tape programmer on a particular project if the expectations and deadlines necessitate it. Because shipping is a feature, a really important feature…
Rule #7. Acknowledge what you don’t know
Refusing to admit you don’t know something or aren’t familiar with a certain technology is guaranteed to waste your time. If you don’t know a certain framework or programming language, don’t try to wing it. Your self-worth isn’t tied to what you’ve memorized; you need to think on a higher level.
Throughout your career, you’ll encounter countless situations where you don’t know exactly how to solve the problem. It could involve migrating data between different systems, configuring a server or performance tuning. You need to learn how to admit your shortcomings and be honest about what you don’t know. Not having all the answers is okay and speaking up when you don’t understand definitely isn’t a sign of weakness.
Rule #8. Learn how to learn things quickly, not how to know it all
You can’t possibly know everything so you must hone your ability to learn new things on the fly. You’ll drive yourself crazy trying to master everything, so don’t. In most cases, you can learn what you need to know pretty darn quickly. Focus on building the skills that let you learn new stuff fast, not on cramming your head with memorized facts.
Rule #9. Never stop studying style guides and learning new languages
Whether you’re a recent graduate or a senior-level programmer, there are always details about programming languages that you could brush up on. Keeping abreast of the latest guides, editor settings and custom tools will keep your code slick and make it easier to work with. Most companies, such as Google, customize style guides to reflect specific practices, so learn these by heart and never stop reading and learning.
Always apply the rules religiously and keep up to date with the latest custom tools that can verify whether your code adheres to a style or the latest editor settings that can help you apply a particular style. Never stop learning. Technology changes so rapidly that if you aren’t continually improving your knowledge and learning new programming languages, you are going to find yourself being left behind very quickly.
Rule #10. Never focus on one particular technology
Technology is not THE solution – it’s how you get to the solution. Many programmers fall into the trap of becoming crazy about a particular technology, be it a new operating system, a new language or the latest JavaScript framework. These are tools for solving problems – not the actual solutions. Tech constantly goes in and out of fashion so you should never put all your eggs in one basket. Learn to recognize that all tech offers benefits and drawbacks. Master as many as you can, don’t just be a one-trick pony.
Rule #11. Strive to simplify solutions
Oftentimes, the most elegant solutions are the simplest but that doesn’t mean they were simple to arrive at. Taking extra care and effort to refine a solution is always worth it. Strive for simplicity; anyone can make a complex solution – your goal should be to create the simplest one. When coding, always aim to write code that is simple to read for developers. Complex code will require time and resources to analyze that far outweigh any benefits that you’d get from optimization.
Rule 12. Build strong relationships
In the long run, your relationships with other developers (and other professionals) will be far more valuable than whether or not you met a certain deadline or shipped a feature within a tighter window. Go outside, play football, hang out, network and build friendships and professional relationships. You’ll find this helps spur your creativity and ultimately opens up better opportunities further on down the road.
Rule #13. Know your development tools inside out
As you gain experience, you’ll naturally get a feel for knowing exactly what to use for each problem you encounter. You’ll have a handle on the range of open source libraries, tools, and frameworks out there from which you can choose. However, if you spend a fair amount of your time coding within a specific environment, you should become a master of your development tools. Whether you use Visual Studio, Text, Atom.io, Emacs or Sublime – it doesn’t matter – you should know exactly how to control it. If you’re starting out, master the easy tools such as Atom and Sublime first and then work your way through the harder options.
Rule #14. Be the leader, not the boss
A boss is anyone who has other people work for them. A leader is someone that others follow. You may not have a title, but you should aim to lead your team and be the person people look to for help. Leaders live in the trenches and have the respect of their teammates. That’s where you want to be.
Conclusion
So, those are our rules, but what about yours? What rules do you keep in mind every day? Which rules do you live by? Let us know, we’d love to hear them!
Anyway, if you are someone who’s striving for continuous improvement and you know a thing or two about programming, we should probably talk. Exellys bridges your ambition to excellence so you can unleash your full potential. So what are you waiting for?
Tags: career , exellyst , framework , innovation , programmer , techie
