Wednesday, October 26, 2016

Top 5 ways to be a better programmer in 2016

Coders make resolutions, no? If your to-do better list is still empty, consider these ideas from other programmers to put to use in the new year. Even the smartest folks have room to grow.

Great tips to help you sharpen your programming skills.

1. Check Your Code First Before Looking to Blame Others

Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them so too might different tools from the same vendor.

When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order.

My personal rule is that if I have a bug I can’t pin down, and I’m starting to think it’s the compiler, then it’s time to look for stack corruption. This is especially true if adding trace code makes the problem move around. Multi threaded problems are another source of bugs that turn hair gary and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount

2. Continuous Learnig

Read books, magazines, blogs, Twitter feeds, and websites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup.

If you really want to get immersed in a technology, get hands on—write some code.Always try to work with a mentor, as being the top guy can hinder your education. Although you can learn something from anybody, you can learn a whole lot more from someone smarter or more experienced than you. If you can’t find a mentor, consider moving on.Use virtual mentors. Find authors and developers on the Web who you really like and read everything they write. Subscribe to their blogs.Get to know the frameworks and libraries you use. Knowing how something works makes you know how to use it better. If they’re open source, you’re really in luck. Use the debugger to step through the code to see what’s going on under the hood. You’ll get to see code written and reviewed by some really smart people

3. Don’t Be Afraid to Break Things

Don’t be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the lifecycle of your project. An added benefit is that your team’s experience dealing with the sick system makes you all experts in knowing how it should work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend his time. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in “one big shebang” will cause enough problems to make you consider abandoning the whole effort midway through.

4. The Professional Programmer

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up to date with the industry and the technology. Too many programmers feel that it is their employer’s job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up to date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: your employer promises to pay you, and you promise to do a good job.

5. Take Advantage of Code Analysis Tools

The value of testing is something that is drummed into software developers from the early stages of their programming journey. In recent years, the rise of unit testing, test-driven development, and agile methods has attested to a surge of interest in making the most of testing throughout all phases of the development cycle. However, testing is just one of many tools that you can use to improve the quality of code.

Back in the mists of time, when C was still a new phenomenon, CPU time and storage of any kind were at a premium. The first C compilers were mindful of this and so cut down on the number of passes through the code they made by removing some semantic analyses. This meant that the compiler checked for only a small subset of the bugs that could be detected at compile time. To compensate, Stephen Johnson wrote a tool called lint—which removes the fluff from your code—that implemented some of the static analyses that had been removed from its sister C compiler. Static analysis tools, however, gained a reputation for giving large numbers of false-positive warnings and warnings about stylistic conventions that aren’t always necessary to follow.

The current landscape of languages, compilers, and static analysis tools is very different. Memory and CPU time are now relatively cheap, so compilers can afford to check for more errors. Almost every language boasts at least one tool that checks for violations of style guides, common gotchas, and sometimes cunning errors that can be hard to catch, such as potential null pointer dereferences. The more sophisticated tools, such as Splint for C or Pylint for Python, are configurable, meaning that you can choose which errors and warnings the tool emits with a configuration file, via command-line switches, or in your IDE. Splint will even let you annotate your code in comments to give it better hints about how your program works.


No comments:

Post a Comment