I think it’s the little habits that define a good programmer.

• Think globally. It’s hard to implment a new feature without seeing how it fits in the big picture.
• Act locally. When adding a new feature, change as less code as you can. It will be much easier to maintain it later. No, your code is not perfect. You will have to maintain it.
• Document your code. This means internal API documentation, and some comments around hard-to-understand parts of your code. Decide on a documenting infrastructure, and use it always when adding new classes, functions, etc. You are doing it for future you. Also, take my favourite quote seriously: “Write code like the one who will maintain it is a maniac psychopath who knows your address.”
• Remove unused code. This is especially true for long-time projects. If there is a code piece no one uses anymore (including your own code), remove it. If you happen to need it later, you can get it back from…
• Version Control. Seriously, you should put everything under VC. Even your smallest side project. Even a tutorial project. It provides you valuable save points.
• Take notes. Every time you have an idea, write it down (preferably by hand, although this advice goes more for meeting notes).
• Read your notes. Obviously, taking notes worth nothing if you don’t read them. Ditch obscure and outdated ideas (but don’t delete them; just strike them through, mark them cancelled, etc.) and add your current thoughts.
• When you have time, make those ideas happen. If you don’t implement them, they are just words. Everyone can write down words. Look, I already wrote 280 of them!
• Read. Read, read, read. About everything. Your favourite technologies (so you can get better at them), your hated technologies (so you can get more ideas from them), non-technologies (because learning is fun), and pretty much everything. Being informed is a must in today’s world.
• Criticise yourself. This doesn’t mean you should beat yourself up whenever you write bad code. Instead, learn from your mistakes, so you get better. Also, a positive critique is a critique, too!
• Be awesome. (Hint: you already are)

That’s all that comes to mind right now. Have fun coding!

The other day, me and a colleague reviewed some source code I wrote a few years back. That source code was written before I joined Hashnode. At the time I was alone, without a mentor, and without a communication network. That source code is horrible.

I think, one habit which made me a better software engineer is joining Hashnode and actively discussing stuff and answering questions. Whenever I answer a question, I do not only try to help someone else, but I also try to get validation if my way of handling a problem is correct. In the beginning, it was mostly reading the answers of others and chipping in now and then, however I started discussing more and more. Now, I rather like writing about my way of doing things and I can see that clever people I meet agree with me. It's an awesome feeling, because this very community shaped me and helped me out a lot over the past one and a half years.

That's even more reason to give back to the community, which helps me again verify if I am still right about things. An upward spiral, if you want.

If you want to become better, make it a habit to write about your knowledge, about what you do, and accept other people's opinions and advice.

I have been writing code for fifteen years, but most of my growth has happened in the last five? What happened?!

Here's a list of daily habits I picked up—none of them seem very big in isolation, just like how a ship's rudder isn't the biggest part of the ship. But when you make some small adjustments to how you operate, like turning a small rudder on a ship you can drastically change the course and direction the whole ship is travelling in.

Here are some of the course corrections and habits I began to adopt a few years ago that I think have really helped propel me in the direction of growth:

• Focus on learning to use a computer, rather than using software
• Dig one layer deeper into understanding the current solutions and tools you use, try to figure out how and why they do work the way they do to solve the problems you're working with
• Create many small throwaway test cases to verify what you have learned - never be afraid to re-write code from scratch (if you are close to a good solution, what you re-type each time from scratch ought to end up looking very similar ;) )
• Learn about the specifications and documentation for the tools you work with every day, and try to understand in which situations they complicate your work. Strive to be able to tell the difference, and understand in which situations each tool is most useful.

Paranoia and distrust. No, seriously.

There are so many scams touted as the latest and greatest things, idiocy like frameworks claiming to be "easier" or to "make you more productive" when they create more work, and flash in the pan technologies that that lose relevance in a year or two painting you into the corner.

From version control subbing for a project manager actually being expected to do their bloody job sucking the humanity out of things, to mind-numbing idiocy like HTML/CSS/ JS frameworks and CSS preprocessors, there's so much 100% grade A snake oil being peddled right now that has no more legitimacy or fact behind it than any of the chazerei being peddled by Paltrow or that derp calling himself an avacado.

I still say my most important skill I've developed in 40 years of programming remains my ability to scream "This is BULLSHIT!". Far, FAR too many developers blindly accept what they are being told and parrot it as the gospel without taking the time to question any of it -- much less learn enough about the underlying languages the framework or other idiocy that is running atop of it to even have a valid opinion on if it is any good or not!

The paranoia also plays well for security since yes, they are out to get you. The only secure system is one with zero access, from there it's all a matter of degree. For example any sane and rational person would EVER be dumb enough to put your SQL hostname, username, and password into a DEFINE in a scripted/interpreted language... Yet there are tutorials and tons of people -- even on major projects -- derping it exactly that way.