Sure, here are some things I do that give me an edge over my peers.
Don’t reinvent the wheel
It sounds obvious, but a large number of developers will develop something without even doing a single google search. You will often find that there are open source libraries out there to do what you need. Libraries that are tested by many, and polished for years. My job is not to code, but to solve problems. I am just as good at my job if I use someone else’s code.
Don’t Repeat Yourself (DRY)
If you are going to do something many times, make it so that you minimize the amount of work each time.
For example, let’s say you will write 100 quests in your RPG game. Spend a few days first writing a framework, each quest should be 1 or 2 lines of code.
Another example I see a lot: a web application where every other method opens a database connection, creates a statement, loops through the result set, all wrapped in a try and catch to close the resources. Instead use AOP or use a framework such as spring data to reduce this boilerplate to 1 line or less.
Automate repetitive tasks
When you are developing code, you will compile it, test it, package it in an installer, deploy it in a server, create tags in your version control system, etc… You will do this hundreds of time. Set up a program (jenkins) that will monitor your version control system, checkout, build, run unit tests, package your code, deploy it wherever it needs to go, email whoever needs to be notified, etc. My day to day workflow is simply changing code and committing it, everything else happens without intervention.
You ain’t going to need it (YAGNI)
Sometimes someone will say: “we should develop X, because we will probably need it later on”. Product owners often suffer from ADD. They will forget about the feature in a couple days. There is a good chance “later on” never comes. Moreover, if you develop X now or later it would typically take the same amount of time. By postponing X, you can focus on the features that are requested right now, and deliver them faster.
Use the right tool for the job
Some developers think the language does not matter. I could not disagree more. Some languages are better at some tasks than others. For example, let’s say you want to analyze an apache log file to find the top requests to your web site. You can write a 200–300 LOC C program to do it, or you can write a 1 line of AWK and get the answer instantly.
Don’t do premature optimization
Write the simplest code first that solves the problem. It should be short, easy to understand, and correct, don’t sweat it if it is not efficient. After you start using the program, if it is fast enough, you are done. If it is slow, only then profile your code, find the bottlenecks and address only the bottlenecks.
Test first then code
You should write a test first. Use frameworks like Jasmine or JUnit. Once you write a test, it should fail because you have not written the code yet. When you are happy with the test, and what your methods should look like, then go ahead and start writing the code. When you pass the tests and get that green check, you are done with this part of code, go and write another test for the next piece.
When there is a defect, write a test using those frameworks. Make sure the test reproduces the problem and fails. Then go ahead and work on the issue until you the green check.
These tests should stay for ever with your code, you accumulate a suite of tests, and you should run all of them over and over automatically with every change. This way, you will catch bugs quickly when you change something.
Refactor constantly
As you write more code, you will think of better ways to do something. Don’t be afraid of going back and change your previous code to make it more readable and reusable. When I look at my version control tool, I delete a lot more code than I add.
If you have a set of tests that validate the existing functions (see previous section) you can rerun them to ensure your refactoring didn’t break something.
Learn to use the command line
It is intimidating and has a steep learning curve. That said, bash is one of the best tools to have on your belt.
We had a large program written in Struts 1.1, we needed to upgrade to Struts 2. A developer says: “well, changing one class takes about 5 mins, and we have around 600 classes so it will take 3000 minutes”. I open up a shell, issue a few incantations in bash, awk and perl, and within 30 minutes the work is done to everyone’s amazement.
To the question in your title, my Magic 8-Ball says:
Hi! I'm a bot, and this answer was posted automatically. Check this post out for more information.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit