Not everyone has the luck to work in interesting projects that allow you to learn while doing your job. Some companies do not even define their technology stack, meaning you don't know what technologies you should learn. Do not despair; you still have many options to build up your knowledge while doing your work.
As software developers we have a great benefit: our work offers us endless opportunities to learn new things. It is the jackpot when you believe in lifelong learning. However, we often do not make good use of those opportunities and end up with the feeling of not learning anything at all. I am convinced that this is due to how we persist our knowledge and the unfortunate idea that learning can't be fun.
We can create a lot of software in a short amount of time. However, code is not everything and there are many important aspects of our application we can’t find in the code. If we document the decisions we make today, then we have a written explanation to help our memory in all those cases where we can’t remember the details. Instead of guessing, we can find answers quickly and persist our knowledge.
For one of my applications I had a simple task: the business needed an easy way to download all PDF files we create in various places inside our application. Offering them one single button who combines all those different files into one big PDF looked like a good idea. Little did I know about all the obstacles I had to overcome to get it done.
One of the simplest improvements for an efficient environment is to define the technology stack you want to use at your company. A little bit of upfront documentation can safe you endless discussions at the start of a new project. Instead of debating what framework you could use, you check if the one you defined is a good fit. Only if this is not the case you go and search for an alternative. Let’s look how you can define your own stack.
How long does it take to learn something? Not 10,000 hours, as many people think. If Josh Kaufman is right and you do not aim to be one of the best performers of that field, you may get away with just 20 hours of deliberate practice. Does it sound too fantastic? It is all a question of how good and comfortable you want to feel by doing it – and how you spend those 20 hours.
Whenever someone talks about learning, it is only a matter of time before someone mentions the 10,000 hours rule by Malcolm Gladwell. His book "Outliers: The Story of Success" is most famous for this rule that after a telephone game ended up being quoted along those lines:
To learn something, you need to spend 10,000 hours doing it.
Knowing just a few keyboard shortcuts can improve your workflow dramatically. That is true for a general-purpose tool like Microsoft Office and even more for Visual Studio. The only question is where to start, then Visual Studio can not only adapt to your needs but also change its shortcuts completely.
Visual Studio Team Services (VSTS) offers a very useful but well-hidden feature: you can have more than one code repository per project. What seams not that interesting can help you to separate code with a different lifecycle and reduce your administrative work. Let's have a look on how you can use this feature.
The SQL Server Integration Services (short SSIS) are a great tool to move data around. Not only are they fast, they have many useful parts to make data migration a simple task. The same is true for their production use. Cleaning up their own database is a feature that most applications completely ignore. All is set-up in a way that SSIS can run for a long time without user intervention.