Yearly Archives: 2017

The Clean Coder: A Code of Conduct for Professional Programmers

The Clean Coder (Robert C. Martin)

You are probably familiar with Uncle Bob’s classic: Clean Code. While Clean Code is about good engineering practices, and writing good code, The Clean Coder is more about communication aspect of developer’s work. It’s about how to behave professionally, be disciplined, and stick to good coding practices. What’s more, it demonstrates how to avoid common pitfalls in software development process. Such as underestimating time, undergo management pressure or cutting corners (AKA writing bad code).

In Clean Coder, Uncle Bob is explaining by example how to communicate at work. Don’t try to be just a “nice guy”. Be professional and responsible, while being polite. There is nothing worse than giving false promises just to make others happy. However, I have an impression that a lot of people are able to get away with that.

Does below sounds familiar to you?

Clean Coder - rush to complete

Do you remember a situation when you thought: “Damn, I wish I didn’t add this test. I would save a day”? What about situation like: “Damn, I wish I did add that test. It would cost me 1 day, but I would save 2 days I spent fixing the bug this test would guard against”? I’ll let you to deal with the answer.

If you don’t want to read entire book, read first 3 chapters. It is a great summary and advice on common wrong doing of most programmers that is not caused by their lack of proficiency, but rather not sticking to their professionalism and discipline.

Ohh…and if you have never heard about Uncle Bob checkout Every Uncle Bob Robert C Martin Video playlist on youtube, his blog, and SOLID principles. Uncle Bob is like your doctor who is telling you that you should eat healthy and exercise regularly. He has similar advises, but about how you should write code.

The Clean Coder is definitely one of the best books I’ve read about Software Development, and I’m adding it to my favorites.

Are you developer? What are your thoughts? Does some situations described in this book happened for you? Maybe you are business person? What do you think? Leave a comment!


C# is dead

In 2012 Anders Hejlsberg started working on TypeScript (JavaScript for C# Developers with types).

In 2013 Eric Lippert left Microsoft.

In 2014 Jon Skeet wrote on his blog about C# inefficiency.

In 2015 JavaScript took over the programming language World for good.

In 2016 C# is getting more functional features from F#.

In 2017 C# is dead.


The Joel Test for 2017

You probably have heard about The Joel Test. This test helps you to determine how good a software team is. It was created almost 17 years ago by Joel Spolsky (currently CEO of StackOverflow).

A lot of changed since then.

Here is The Joel Test for 2017:

  1. Do you fulfill all 12 requirements from The Joel Test?
  2. Do you have unit tests?
  3. Do you have integration tests?
  4. Are you doing Code Reviews?
  5. Do you have Continuous Integration?
  6. Do you have Continuous Delivery?
  7. Can you deploy new version every day?
  8. Is every area of “project specific expertise” covered by at least 2 people?
  9. Can you setup developer environment automatically?
  10. Can every developer run full test suite in less than 1 hour (locally or remotely)?
  11. Do you have telemetry and logging to reproduce users’ behavior?
  12. Are you making decisions based on data?

What is missing? Let me know in comments!


I created Windows app over the weekend and you will not believe what happened next

Pomidoro

Over four years ago I created a simple Pomidoro Windows App in order to learn Windows RT app development. Yeah! Windows RT was a new thing back then! My app was a simple timer that counts down from 25 minutes to 0. It was designed to use when applying the Pomodoro Technique. I published it to Windows Store as a free app. Since then me and a few friends of mine were using it. It made it to top 600 productivity apps on Win Store.

The main purpose of creating this app was to get insight into Windows RT apps development, and experience publishing app to Windows Store.

Last year, somebody from Pomodoro Technique filed Content Infringement Complaint stating that

App name has a name including “Pomodoro Technique®” and “Pomodoro®” or significative parts or misspelling of Pomodoro and Pomodoro Technique

What that means? My app, created over the weekend, is serious competition for their app. What’s more, they removed my app from Windows Store!

good job meme

Recently, my friend Pawel Sawicz – who co-founded dotNetConfPL with me – asked me about this app. He was using it from day to day, but he got a new ThinkPad X1 Carbon Gen 3, and he had to install a new system. When he wanted to install my Pomidoro app from the Windows Store he couldn’t find it. He thought that the search was broken. Then he reached out to me, and I explained him the situation. Fortunately, source code is on github.


How we saved $1,000,000 for Microsoft with this one, small change

British Cycling Team - 2012 Olympics

Everyday when I am doing some small bug fixes or minor improvements I am thinking about the British Cycling team. They dominated 2012 Olympics thanks to marginal improvements. Such as cleaning hands properly, taking their own pillows when traveling or sleeping in the right position. All of these small things put together resulted in 7 out of 10 track cycling gold medals.

It turns out that the same strategy might work in software development. Especially if you work on large project.

1 million dollar improvement

In Azure Portal we have hundreds of developers working on one codebase. We are using MSBuild to perform builds. With default options, MSBuild was printing out to console a lot of logs that weren’t very useful. When you are building project, you are usually interested in errors. It turned out that changing verbosity of output speed up builds from a few seconds to a few minutes depending on the project that is being built and type of the build (incremental / rebuild all).

Taking into account that there is at least 100 developers working everyday on the Azure Portal (in fact there is much more, but not everybody is working on the Portal full time), and assuming that everybody is performing at least 20 builds per day (savings up to 30 seconds per build), and 4-5 full project builds (savings around 1-2 minutes), every developer can save around 20 minutes everyday!

This gives us:

100 developers x 20 minutes x 240 days working days per year = 480,000 minutes = 8,000 hours

Assuming ~$150/hr  it give us total savings: 8000*$150 = $1,200,000

Incremental changes over years

When I am looking back, I am impressed how much the Azure Portal have changed over last two years. This is portal in 2014:

Azure Portal in 2014

This is portal in 2017:

Azure Portal in 2016

We haven’t done any breakthrough changes overnight. I have never had a feeling that one day resulted in some significant difference. It was 1 step at the time, one small bug fix one day, one tiny part of new feature another day.

Small improvements every day, everywhere…

This applies not only to large scale project. Think about Open Source. Even when you are doing documentation improvements for ASP.NET docs, you can save time for hundreds of developers. You are not saving particular company’s money, but you are saving our (developers) money and what’s even more important, time that can be invested somewhere else.

Another great example of small incremental improvements is John-David Dalton. Creator of lodash. He is contributing code on github every(!) day for a few years now. This is his github contributions chart:

John-David Dalton contributions

No white squares. Some of his daily commits are tiny, some are small. By being consistent every day, over years he was able to create one of the most popular JavaScript library.

What small improvement can you do in your project? Think about it, and remember that best ideas are born when you are away from your computer!