Why C# is Still Worth Learning Today

These days with all the programming rage is JavaScript and related web frameworks or data science with Python or R, C# isn't as popular as it used to be. Of course, that makes sense. Programming languages come and go as languages and compilers are evolving. However, I think C# is still a good language not only to learn but to master.

It Used to be Very Popular

With the recent release of StackOverflow Trends we can see how popular tags have been on the platform. Considering how popular and influential StackOverflow is in terms of getting help, this data is worthwhile to look at.

Here's a look at the current list of popular languages according to TIOBE index (we'll talk more about this further down this post).

That's a lot to gather in one chart, so let's break it down a bit.

From this graph, C# was very much used due to the amount of questions on StackOverflow back around 2009.

Sure, it has steadily gone down in time and will probably continue to decrease. But think, all of those companies who picked up C# and .NET back when it was much bigger...they need to support those applications. Some may decide to rewrite them depending on their budget and what kind of experience their current developers have, but I'm sure C# will continue to run a lot of those applications in the future.

This reminds me of the current state of Cobol. A HackerRank post mentions an interesting statistic about Cobol:

70-80% of all business transactions worldwide are written in COBOL today

That's a lot of businesses still running Cobol! I believe it'll be the same with C#.

It's still popular...

Every year for the past few years StackOverflow has conducted a big developer survey. What they find there can be very interesting!

Here's the most popular technologies of 2016:

https://insights.stackoverflow.com/survey/2016#technology-most-popular-technologies

Most popular doesn't always mean that developers enjoy working with it, does it? In terms of C#, it seems developers still enjoy it!

https://insights.stackoverflow.com/survey/2016#technology-most-loved-dreaded-and-wanted

C# is here to stay

Developers still ejoy working with it, but what about the industry itself? All of the data presented so far was from StackOverflow which was derived from surveys, where people can lie if they want, or from their own data with tags, which just means people ask a lot of questions about it. The TIOBE index mentioned earlier gathers a lot more data. Here's their list of the top five languages:

Source: www.tiobe.com

Still impressive to be in the top five and I don't see it getting below that very much in the near future.

---

With all the debate about what will be next to learn to keep you on the edge in terms of development, a good solid understanding in C# is still a contender. Not bleeding edge, of course, unless you're getting alpha of the newest C# versions to try out new language features.

C# is a great languge to learn from since the tooling is great and there is no shortage of tutorials and courses for it.

Book Review: Coders at Work

There are quite a lot of interviews with software developers out there. Though, I doubt there are many that feature such an array of accomplished developers as Coders at Work does. In this book, there are quite a few words of wisdom from developers who have been through the tough bugs and the long projects.

When I first got this book, most of the names I didn't recognize. In fact, there were only just a couple I did recognize by name - Donald Knuth and Douglas Crockford.

It was very interesting getting to know the other programmers in this book. Perhaps the most interesting reading in it, I felt, was the blurbs that introduce each person. Telling what they accomplished, what they're currently working on, and a sentence or two of what they talk about in the interview. The most fascinating thing is learning how each individual person being interviewed contributed to the world of computer science.

There were quite a few take aways from this book that may be applicable to everyday work. The biggest of these, though, is that most of the people being interviewed, when asking about how they debug a program, still use the very reliable print statement. In fact, there's this MIT open courseware lecture on debugging that just goes over exactly that!

Here are a few other items of note that I learned while reading this book:

Jamie Zawinski gives advice to not be afraid of what you don't know and that it's ok to ask someone who does about it.

Joshua Bloch says that it's important to know what you're trying to build before you get started. He suggested a talk he gave a quite a while ago now - How to Design a Good API and Why it Matters.

Joe Armstrong has a few nice pieces of advice.

• He gives a really good debugging technique for finding errors which is that all errors will be three statements before or after the last place you changed the program.
• He mentions that documentation tells you what the code is supposed to do. "Just read the code" will tell you what it does. Sometimes they aren't the same thing.
• He mentions a nice talk by Richard Hamming, "You and Your Research", that has a lot of advice such as...

If you don't do good stuff, in good areas, it doesn't matter what you do.

Simon Peyton Jones mentions an interesting paper on "Why Functional Programming Matters". Which has been turned into a talk!

Ken Thompson knew for a long time that working 60, 80, or even 100 hours a week will definitely generate burnout. External deadlines also definitely generate stress.

---

There's a ton more to learn from this book. From here you can step into the shoes of programming greats and learn the lessons they have learned.

Git Commands I Can't Live Without

Git has definitely become the main version control system developers use lately, and I admit, I got on that bandwagon when I got more into GitHub. I wanted to be more familiar with Git since I was doing more and more with GitHub.

I'll also admit, and I may be dating myself here, my first version control system that I used was StarTeam. Never heard of it? I don't blame you. Just look at the interface it had:

View fullsize

StarTeam interface

I used that for a few years until the company got rid of that and went to Team Foundation Server. Definitely a step up from StarTeam, but then I got started using Git. The more I use it the more I enjoyed using it.

However, I didn't get an appreciation for how powerful it was at first. I first started using Git when GitHub had their GitHub Desktop applications and used that for a while. I also used SourceTree on one project I was on.

While these applications are great, I still wanted to learn more about the commands these applications are running in the background. That's when I started to only use Git through the command line. From that challenge I set myself, I realized there was way more to Git than these applications may show. Below is a list of commands I've been using quite often, but feel they may not be as well known.

Stash

If you ever need to quickly put your current changes away so you can help work on something more important than your current task? Well, git stash is here to the rescue!

Just type in git stash and your changes are "stashed" away.

Stash newly tracked file

Now I can move on to working on something else while keeping my changes away for me to come back to.

You can have many as many stashes as you need, as well. If you're not sure of the ones you have, just do a git stash list and you'll see them all.

List of git stashes

Oh, but you want a meaningful message when you stash to you have an idea what changes are in it? Git has you covered there, too! Just do a git stash save <message here> and git will save the stash with your message.

Save git stash with a message

So we can save stashes in a couple of different ways, but what if we want to go back to a stash to continue our work? We have a couple of ways to do that, as well.

If you want to just apply the latest stash, just do a git stash apply.

Applying the latest stash

If we want to apply a specific stash we can just do git stash apply <stash name>.

Apply stash by name

“Note that, if you’re in PowerShell and try this command it won’t work. To get it to work, you’d have to put the stash name in quotes.”

Diff

Sometimes, you just want to double check the changes you've done before adding and commiting. In that case git diff is there for that.

Git diff results

No need to go to a separate application just to see what the changes are. You can just look at them in the command line.

---

With all this said, though, there is still a ton more commands and uses that Git has that I probably have never even heard of. Because of that, as y'all could probably guess, I got a book for it!

I'll definitely be reviewing this after I go through it to let y'all know how it is overall. Just going through the table of contents indicates that it covers a lot of really useful commands.

What git commands can you not live without?

Book Review: Deep Work

Soon after I was about to finish So Good They Can't Ignore You, I stumbled upon a post by Ryan Holiday (another author I frequently follow), and it mentioned another book by Cal Newport - Deep Work. I thought a second and realized, "I think I have a book by that name." I go up to my library and, sure enough, there it is on my shelf. So when I finsihed the current book I was reading I picked this one up. I expected to receive similar benefits as I did in his previous book that I just finished and, sure enough, I got some good insights and advice from it as well.

The first part of the book goes into how deep work is valuable, yet it's increasingly rare in our work environments. In fact, the author goes into two core abilities you must have to thrive in our work environments. You must have the abilities to do the following:

• quickly master hard things
• produce at an elite level in terms of both speed and quality

These two abilities, though, depend on your ability to perform deep work. The author pretty much sums it up in this statement:

If you don't produce you won't thrive - no matter how skilled or talented you are.

This makes sense, of course, but what we may currently produce may not be the best value that we can give.

Deliberate practice needs deep work

You may recall my current strategy for doing deliberate practice for my programming career. However, doing deliberate practice in itself is a practice in deep work because core components of deliberate practice are

• Having tight focus on a specific skill you’re trying to improve or an idea you’re trying to master
• Receiving feedback so you can correct your approach to keep your attention exactly where it’s most productive

The first core component of deliberate practice is getting deep work done on the skill or idea you're working on to master. The second component is essential so you can receive feedback to better tailor your next deep work session so you can continue to improve.

In order to produce great work that is valuable working for extended periods with no distractions at all is the key. This is essentially what deep work is, and it is essential to getting the deliberate practice you need to master a skill.

Enemies of deep work

Earlier in this post I mentioned, as the author does several times in the book, that deep work is very valuable, yet it is very rare in current work enviornments. If it's so valuable why isn't it happening more?

The author gives several reasons why, but one of the biggest enemies of deep work is the need to always be connected or to always be reachable, whether through email or through a chat application. I always knew that email was a big distraction from my readings of The Four Hour Workweek. You'll save so much time by scheduling when to check email and only do it, at most, twice a day. Another connection it drew in my mind was, in the Tim Ferriss Podcast episode with David Heinemeier Hansson, DHH (as he's often refered as) goes into how they get so much work done. Once you listen its very simple how...they're able to get deep work done often. The whole company seems to love being able to get deep work done. From a post about working four day work week they mention how they reduce or completely remove the common distractions one can have during a typical work day. Meetings, email, and chat can be very distracting and will remove your concentration causing you to not get much deep work done.

As I say this, me and my company do a good bit of email and we have even adopted Slack as our main way of communication. This doesn't mean that we have to change our ways as a company or anything. This simply means that we have to be more mindful of how we are personally using these tools.

It's ok if we don't immediately respond to an email or chat message. Nothing work related is going to be life or death. The author even mentions a small study done with a group of management consultants at a very big company who were asked to disconnect for a day. Naturally, the consultants were nervous that the clients wouldn't like that, but it turned out that the clients didn't care. People will usually respect your right to become inaccessible as long as those periods are advertised in advance, and are able to get in touch with outside those periods.

How can this help your programming career?

The author cites a great book for developers on honing your craft, The Pragmatic Programmer:

We who cut mere stones must always be envisioning cathedrals.

As developers we are constantly trying to hone our craft of programming. There's always something new to learn in our field, whether we want to stay up-to-date or to go in a different area. Deep Work has good advice to do deliberate practice and ways to change your work day so you can get as much deep work done as possible.

Even in your day-to-day work what you produce can be greatly expanded if the rules of using deep work are applied. Outside of your daily work, incorporating these deep work rules can also be of great use. Going through training material or working on that side project will yield better and quicker results if they are done as deep work.

---

There were some great insights from this book that I plan to incorporate in my own working life. Even turning off email and checking it on a schedule, I believe, can yield great results. I recommend this book if you feel like you can do more during the day but not quite sure of how it can all be done. It can be done and this book shows you a few ways to get there.

Why I'm Reading Research Papers

In my recent post on doing deliberate practice to become a better developer I mentioned that I was going to spend some time to read and understand some research papers. This may seem a like an odd thing to do in order to become better at my craft, but I figured a little experimentation couldn't hurt. At the worst, I'll have a few research papers read and understood. Perhaps I'll even meet one of the co-authors and have something to engage in discussion with. However, I believe I may get a bit more out of it than just that.

Understand Latest Research

Seeing what the latest research trends are, I feel, can be quite beneficial in a practical sense. For instance, there's a paper that suggests that simple testing can prevent most critical failures in software. From reading the paper and Adrian Colyer's post about it one can get a lot of insight about preventing most crashes in software. One having that insight, you can put it to good use in all of the software that you currently are developing.

See Cutting Edge Technologies

I'm sure most of y'all have seen this graph on emerging technologies.

View fullsize

CC BY 2.5, https://en.wikipedia.org/w/index.php?curid=11484459

Keeping up with new research articles allows me to be a part of the early adopters. Whereas now, I'm most likely split between the Early Majority and the Late Majority. Getting in early to new technologies will give multiple advantages, such as being among the first to submit pull requests if they have their code on GitHub, or generating the first set of blog posts on the subjet.

For example, Elm, a functional web language that outputs to JavaScript, was first introduced as a research paper. While I would say it is still in the late stages of the Early Adopter phase, if I was able to get on it earlier soon after this paper came out I could be considered one of the go-to people for this technology and even could help contribute to future releases of it.

Try to Understand More Math

A lot of computer science, and especially most of the research done in the field that I've seen, has a good bit of math behind it. While I took some math in my own studies of computer science, a lot of that was lost due to just not using it or keeping up with it.

While it's not necessary in day-to-day programming, it can be a bit helpful. Learning the math can help develop that extra bit of logic that will help in my daily programming, whether business logic or debugging.

---

With these benefits in mind, I plan on reading a paper a quarter this year and see how that goes. I'll definitely report back any benefits, or lack of any, that I believe I receive during that process.

My Deliberate Practice Plan to Become a Better Programmer

In the previous post, I reviewed the book So Good They Can't Ignore You. I wanted to take the ideas and advice from there and to create my own plan for deliberate practice as a software developer. Here's what I came up with...

Continuous learning

Being a software developer means to always be learning. Whether it's a new framework, new programming language, or a whole new programming paradigm learning something new is integral.

There are several ways to do this and I will try to incorporate all of them, though more will take more presidence and attentnion than others.

• Use sites like Pluralsight and Udemy for on-demand tutorials and training.
  • Watch at least one course each one or two weeks, depending on the length of the course.
• Watch at least one software presentation on YouTube or similar site.
  • Watch one at least each week. This should generate some "Top 10" posts for everyone to enjoy or, if it's really good enough, a post about a specific presentation.
• Read at least one technical book each quarter.
• Read and try to understand at least one journal paper on programming each quarter.
  • I plan on starting with this list. From there the Papers We Love site looks to have a ton more to go through.

Practicing

Of course, one of the biggest and best things to do as a developer is to actually program something...anything to help put into practice what I've learned. The above methods are great for learning new things, but they have to be put to use, as well, otherwise I won't be able to retain what I've learned.

• Have at least one personal project going at a time.
• Blog about things learned and always have a demo project for it, if possible.
• Get certified, if available.

Being uncomfortable

Doing deliberate practice often means being uncomfortable during the practice. This is an easy way to know if the practice is good or not. Here a couple of ways I can step outside of my comfort zone.

• Speak at a local user group at least once each quarter.
• Try to speak at a conference at least once this year.
• Do more screencasts instead of regular text posts for the blog.

Keeping track

Now, none of the above doesn't mean all that much if I don't keep track and accoutable for each of these. Saying I'm going to do it doesn't mean I am going to do it.

• Once again, blogging about each of the above items as much as possible
• Use a time tracker such as Plan to keep a digital record and for some nice reports.

---

Since it's very close to the 2017 year, this is a great time to get started with this.

Do you have something you've done work very well for you but wasn't mentioned? What are your plans for having deliberate practice?