Jeff Nelson, a former Googler and inventor of Chromebook says on Quora, “One habit I've clung to is writing small prototypes when I'm trying to learn new concepts.
For example, I'll sit down with a book or a web page, and over the course of a few hours, write 30 or 40 programs all of them only a few dozen lines long.  Each program intended to demonstrate some simple concept. This prototyping makes it very easy to try out many concepts in a short period of time.”

Teaching You Tools to Become Empowered

To build a successful business and career, you must always keep up with changes in the IT Marketplace. AWS, Office 365, LinkedIn, Sales Force, SEO, Social Media are just a few examples of where knowledge is a huge factor for success.

Training with HSG addresses your knowledge gaps and provides you with the requisite tools to outpace the competition.

Miguel Paraz, Software Engineering Student habit is to “keep a log in a text file or document on my work computer. Before trying to solve a problem, I write it down first. And then I describe the details as they happen.”

Damien Roche, freelance developer has “a set of notes entitled "Brick walls". Every time I run into an unexpected problem that takes me an unnecessary amount of energy to solve, I log it in my list, along with the final solution, and suggested resources so I am prepared next time. My progress is then measured by the amount of brick walls I encounter. If I stop logging to that list frequently, I'm probably not challenging myself.

Debasish Ghosh. author of DSLs In Action, “In no specific order, here's a list which I try to practice ..”

• read lots of good and bad code. Reading bad code is equally important as it highlights many anti-patterns
• use exploratory mode when trying to solve a problem. In other words I use the Repl to get immediate feedback on the segments of problem I am trying to solve
• use divide and conquer policy when solving complex problems. I try to start with a simpler subset and then explore towards complexity
• try to read at least 1 paper per week that's not directly related to the work I am doing right now. I found this extremely helpful to increase the breadth of my knowledge
• always try to be associated with a pet project, besides your own job, preferably open source

Aryeh Friedman, Lead Developer…

1.       Fanatical about unit and fully automated integration testing (I leave the border cases for a bug to trigger them before testing them though)
2. I always look for the best tool/solution/methodology for a given project regardless of what conventional wisdom says to use
3. Fanatical about setting up systems that protect me against myself without putting me in a straight jacket for example Aegis 4.24forces me to actual doing testing and ensures that one other human (if one is available) looks at my code before it goes out the front door
4. Lazy pair programming... namely each person in the pair is working on their own stuff but each know enough about the others work they can help with debugging and discussing various tradeoffs with
5. Find anyway I can to avoid write code vs. solving the problem some other way without compromising performance
6. Avoidance of dangerous language features like "spooky" reflection in Java (stuff that lets you break encapsulation)
7. Keeping my methods and code as simple as possible (if they are longer then half a screen or I have an irresistible urge to break them up [this rarely proves wrong])
8. Fix bad code smells immediately
9. Design my work for what can be done between smoke breaks (45 mins to 1 hr) this is very good for figuring out how to break stuff up
10. Design top down and code bottom up

Michael Moser…

If you don't understand why something is happening in your application or with a certain line of code, don't say "well it's working" and move on. Get to the bottom of it and make sure you fully understand why.  Otherwise it *will* come back and bite you later. Break big problems into small ones and consider Single Responsibility Principal always.  Only start writing code after you have a solution. If you need to test some ideas, use a spike/prototype but do not just start coding.

Related:

How do top programmers work?

How to Keep a Start Up Team Motivated?

How important is it to exercise for people in technology that sit for hours on end?

What is the most pressing problem in Project Management for a Software Project Manager?