I'm sure this is something that a lot of people would agree with. But in case you're still on the fence about standing desks, hopefully this post will help make up your mind. I have had a standing desk for 3 years. It has changed the way I work ever since.
For one, I'm not sitting as much. That sounds obvious, but really think about how much we sit every day. Sitting while driving or riding the bus on our commutes. Sitting at the desk. Sitting in meetings. Sitting on the couch when we go home. That is a lot of sitting! After getting used to a standing desk, I don't feel as worn out at the end of the day. Just a quick search can reveal all the health benefits of a standing desk.
As developers, I'm sure we have experienced those glorious wired in sessions—when we're lucky enough to have uninterrupted time to focus on a task. When I had those sessions and got stuck on a problem, it was so easy to just sit in one place and stare at the screen for hours, giving myself a tunnel vision on the problem. With the standing desk, it became very natural for me to just walk out of the desk, take a deep breath, maybe get some water and look at the problem from a different perspective.
Another minor benefit I find with the standing desk is it's a lot easier to show someone your screen. The person doesn't have to find a chair, or awkwardly crouch. You both will just be standing!
These are just the few things that came to mind. I'm sure I have forgotten something. In the end, I believe standing desks are beneficial to developers in general. One should get a standing desk if possible.
Edit: As some good folks on Reddit pointed out, there's one thing I forgot to mention. While it's not good to sit all day, it's also rough on your body to stand all day. If possible, get an adjustable standing desk so you can take "sitting breaks." I personally just have a high stool and keep the desk height the same.
P/S: Some employers are more than happy to pay for your standing desks
A few months ago, I created a bot to scan GitHub for publicly exposed Azure Storage connection strings. The bot then notifies the repository owners (to its best effort). What gave me the idea? Well, I accidentally pushed a connection string to GitHub. Even though it was a personal demo project and there's no sensitive data, I thought that it was still a poor practice on my part
Upon launch, the scanner quickly found a multitude of exposed connection strings. Since then, it has been detecting about 100 some valid unique connection strings per month:
The numbers aren't really too surprising. It's so easy to just hard code the connection string somewhere and tell yourself "I'll remove it later. Just let me quickly get the prototype out." Guess what, if you're using GIT and making commits along the way, it's in your commit history.
Environment variables to the rescue!
Since then, I forced myself to put all the connection strings, application IDs, and application secrets in environment variables -- even for personal or demo projects. Why environment variables? Because most popular hosting platforms support them. Here are a few reference links to managing app configurations: Azure Web Apps, Azure Cloud Service, Heroku, App Harbor, etc.
I recognize that even environment variables aren't 100% safe. It's probably okay for mid size applications that can afford to have "secrets" in memory for a short period of time. If your application is handling million dollar transactions, I'd recommend looking into Azure Key Vault.
Recently, someone from our team sent out a code review. I noticed that the call to base() from some class contructors were automatically removed by ReSharper. At first I didn't think it would make a difference, then I got curious and did a little testing. There's a subtle difference between explicitly calling the base() constructor or let the base constructor called on by .NET.
The code below results in the following output:
With or without the base() call, the base constructor is called anyway. It appears that specifying base() calls the parent constructor as if the method is being called from the child constructor. This behavior seems to be consistent among .NET 4.5, 4.5.1, 4.5.2, 4.6, and 4.6.1. I have not tested this on a machine without .NET 4.6.