Why should you use popular technology to build software for business?

Our industry is overwhelmed with a number of programming languages. Every good computer scientist or a programmer interested in programming languages strives to create his own language. Today you don’t even need to be extremely smart to do it. Take a look at JetBrains MPS beast. With this tool, you can put together your own language literally in few hours. I believe it is important to distinguish languages which you can use for businesses and language which you can have fun playing with. And it’s better to avoid crossing the line. If you stop your education on widely used language like Java it is bad for you. But much worse things will happen to you and your company if you start or continue using for your business some exotic or old language, like COBOL or SmallTalk. Many people think that it does not matter what language you use because each of them can provide sequential, conditional and repeating operations and this is pretty much all you need. I was among those people few years ago. And while this is true, you can write almost any program in any Turing complete programming language, after trying working in both, a popular and exotic language, I would firmly assert: it matters a lot. And here is why.

Popular programming languages tend to form whole ecosystems around them containing tooling, plug-ins, frameworks, libraries, platforms, developers, vibrant communities with support forums, open-source foundations, vendors and companies which build solutions using all these components. This is millions of people and dollars, huge moving, innovating, self-maintaining organisms. A lot of energy and manpower. You can probably easily guess what languages managed to build such ecosystems: C, C++, C#, Java, JavaSsript, PHP, Ruby, Python. All others are lagging behind. If you develop software with programming language, which does not have powerful ecosystem, the following will inadvertently happen to you.

Main rule of software economics, which doesn’t build stuff which you can avoid building, will be broken. You will have no choice and will build all frameworks and tools on your own. Sounds great, but it is a very sad situation. You will spend too much of resources on maintaining these things, which are not related to your business directly. And the worst thing is that all these spendings will not help you with hopeless lagging behind others, who can cheaply buy or even take for free all those tools and frameworks. New programming technique has established? Like TDD or refactoring? Those who are in ecosystem just download tooling and start using these techniques. However you spend resources, which you could have spent on developing apps for your customers, on this tooling. Results are of the low quality, of course, since your resources are limited. All this leads to… Isolation. Since you can not cope with the pace of the industry, based on vibrant software ecosystems, you will isolate yourself from the rest of the industry. You will not introduce TDD, refactoring, continuous integration, continuous delivery, micro-services or any other development practice or architectural pattern into your organization. Consequences:

  1. StackOverflow will never help with any technical problem. Your developers will constantly distract each other asking for help because the world community is simply absent;
  2. Your developers’ effectiveness will drop considerably, they will spend most of their time fighting with the code and bugs;
  3. The technical debt will grow in frightening speed;

What comes next? Demotivation. Your people will start with great motivation at your company. They will try to bring the best practices they know about making software to your company. But very soon they will discover that they just can do nothing without proper tool support, which you can’t give because you have to focus on your customers, not on tools for you developers. People will stop learning and developing themselves. They will stop refactor and test their code well. Who cares? The code and architecture is a mess anyway. This situation will slowly formulate your technical culture. And this is a dangerous situation because best people will avoid working in such a culture while it will attract people, who don’t care about their craft. This will make your organization even less efficient.

From individual developer’s perspective, your career will be put in danger. If you develop software in isolation from the industry and use unknown, home-grown, low-quality technology, no one will be interested in paying you for your services. You will eventually become uncompetitive.

This same idea works for any other technology like framework or library or platform, not only for a programming language. For example, I have built this site using WordPress, which is extremely popular. Before that, I was maintaining my site made by myself. It was a total pain, I spent hours to make minor changes. This site, nechai.net, was made during two evenings after work. And it has absolutely EVERYTHING I can imagine putting on my site. All free and high quality. If I will need something specific, an army of companies and freelancers will be ready to help me for very small payment. Amazing, is not it?

Now, you can object, that giving such an advice puts innovation at risk. Yes, I agree. If you only do popular stuff, innovation will not happen. But is your business is to bring something new to the world of technology? If not, why should you or me care? My business was to create this site. I could have given a use case for some new progressive content management system, but I did not. Instead, I just seamlessly and fastly created what I needed to bring some content to you.

I would make an exception though for the case when you want to make some investment in a new language. When you believe it will become popular and will build a powerful ecosystem. In case of success, you might end up to be a big fish in this a future ecosystem. But be careful, there are so little count of really popular languages and a huge count of forgotten and niche ones. Your risks become lower if your language is a part of some other’s language ecosystem like TypeScript and CoffeeScript are the parts of JavaScript ecosystem, Scala and Groovy are the parts of Java ecosystem.

All right, so what is the conclusion? Well, it is in the name of this article. Program in popular languages for your business and remember, our job is to provide software, not to write code. Teach yourself programming using exotic languages. Don’t mix things up, unless your business is technology and you want to invest into some new raising shiny language (or framework or library or platform). Luckily most companies understand this. See how most of them stick to Java or C#.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

My 7 favorite code design authors

In this post, I would like to share the list of my 7 favorite authors on code design. Books, articles, and courses from these guys made a huge impact on the way I code today. All of them have written at least one book which focuses on code design for maintainability, understandability or readability. These books are very interesting to read. When you finish them, you feel enlighted.

Robert C. Martin. It is hard to explain why I like this guy so much! I believe he has made the greatest contribution to the clean code movement. He focuses on having everything clean. His books (especially Clean Code one) are on every developer’s shelve. His presentations are really fun to watch. I think everyone should do presentations this way, otherwise there is no real need to do a presentation. People can always read the information on the web without spending much time listening to you. Robert has always deep insight. Most of his appearance makes me think hard on the topic. And his clean coders videos are awesome: entertaining and teach a lot!

Martin Fowler made a huge impact to the code design by his refactoring book. Maybe he is not the one who invented refactoring, but he is the one who brought refactoring to the everyday practice of millions of developers. Although Martin focuses on enterprise systems design, he very often writes a lot of useful information on code level design on his Bliki. He also wrote a very interesting book, on domain specific languages. This book did not become very popular, but it is extremely interesting from the code design point of view. For example, there you can learn how to design fluent interfaces (which are very popular in today frameworks).

Mark SeemannMark Seemann is the author of well-known in .NET community book Dependency Injection in .NET. Although the book is somewhat specific, I enjoyed very much Mark’s Pluralsight courses. Especially the course Encapsulation and SOLID. What is interesting about Mark’s stuff is that he brings a lot of functional practice into ordinary OO coding. If you like to learn how to write clean code in the functional language like F# or how to improve the ‘cleanness’ of your OO code with functional techniques, you should definitely check out his blog and Pluralsight courses.

Michael Feathers wrote a great book named Working effectively with legacy code. There you will learn that author understands that real-world programming is not as beautiful and easy as it is in simple code examples. Michael gives guidelines how to deal with ugly legacy code out there (who managed to avoid working with a legacy in his career?) and gradually arrive at the better-designed code. This book is very good help for those who are overwhelmed with huge legacy systems and just don’t believe that clean code rules and principle could help them or are of any value in their situations. Michael continues writing on code design on his blog.

Steve McConnell is the author of the seminal book Code Complete. This book is rated in many polls as the best book on software engineering out there. And I would agree. Although the book is ancient (taking to account the speed of our industry) it is still widely bought and read. People still develop code construction courses and video tutorials based on this book. If I was limited to read only one book in my career, I would most probably choose this one. Unfortunately, Steve seems to stop his activity in code design/construction area. I can’t see anything new from him on the web and conferences.

Roy Osherove. You probably will be surprised to see him on this list. Roy mostly works in the unit testing area. But who said unit tests are not code? All automated tests are code and all this code should be clean as well as production code. Otherwise, its value will be neglected with maintenance cost. And this is Roy’s book’s, The Art of Unit Testing, main idea and focus. He teaches you the way you should design your test code to avoid maintenance nightmare. Roy is still active on the topic, writes blog posts and records a lot of video on automated tests design. All of this content can be reached here.


Douglas Crockford/Jon Skeet
. Yes, 2 guys. But I did not want to break nice number 7. And they somewhat belong together, because on the 7-th position I wanted to put language, guru. But everyone develops in his own language. As .NET web developer, my languages are JavaScript and C#, hence gurus are Douglas Crockford are Jon Skeet. There are many experts on these languages, however. Why did I pick this couple? Because they care a lot about creating clean, maintainable code in their languages. They research, speak and participate in language development with clarity and readability in mind. Douglas’ JavaScript: The Good Parts and Jon’s C# in Depth are masterpieces. If you follow these guys closely, you will master not only JavaScript and C# but you will also learn how to design maintainable code in these languages. Also check out Jon’s videos specifically devoted to code design in C#.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Якими навичками та рисами має володіти сучасний програміст?

Найважливіше розуміти яких навичок від тебе вимагає HR. Маючи ці навички, можна одразу потрапити на співбесіду. Те, що їм потрібно можна почитати в описі вакансії. End of story. Я на напишу якими на мою думку (думку програміста) навичками має володіти людина щоб стати успішним програмістом. Одразу скажу, у мене самого і половини цих навичок немає, але як приємно спостерігати за людьми у кого вони є, бачити з якою легкістю вони справляються зі своїми завданнями.

Гарна пам’ять. Трохи дивно, чи не так? Але що може виробляти програміст з гарно пам’яттю! У мене є кілька таких колег, одна з них пам’ятає шкільні вірші на пам’ять. Вони пам’ятають як система працює в цілому. Пам’ятають як працюють її окремі частини, у чому суть тієї чи іншої функції, де шукати ту чи іншу функціональність. Кожен раз, коли вони торкаються якогось коду, вони пам’ятають його суть. Можна прийти і запитати їх через рік, що той код робить, і отримати відповідь. Я, напевне, ніколи не перестану дивуватися. Коли працюєш з великою і складною системою, цю рису важко переоцінити.

Уміння бігати в мішку. Як пояснити цю якість? По-справжньому її можна лише відчути, але спробую. Це щось типу кладеш цеглинку за цеглинкою в рівненьку стіну, все гаразд, але тоді ти бачиш, що хтось поклав цеглинку поперек, а ще хтось пропустив цеглинку і в стіні дірка, а ще хтось замість цеглинки купку лайна наклав. Людина, що має цю навичку зорієнтується, не розгубиться, не побіжить скаржитися чи просити допомоги. Вона якимось чудодійним способом розрулює ситуацію і далі кладе цеглу, і проект триває. Косяки є на кожному успішному проекті й уміння з ними жити і деліверити – дуже цінне вміння.

Розв’язування задач. Не те щоб ця навичка була дуже критичною, бо в корпоративному програмному забезпеченні рідко трапляються задачі, які потребують вміння розробляти алгоритми та оцінювати їх складність. Але все ж таки трапляються, а в не корпоративному, гадаю, трапляються ще частіше. І важливо тоді, коли це станеться, не завалити проект.

Управління складністю. Програмне забезпечення дуже складне. Людина нічого складнішого не виробляє. І якщо програміст не вміє зробити код і архітектуру максимально простою, робота з системою, що він розробляє, швидко перетворюється на пекло. Ми проводимо 80% часу читаючи код. Якщо зі складністю не змогли впоратися – читаємо 95% і більше часу. А коли ж писати новий код?

Управління залежностями. Залежності можуть приймати найрізноманітніші форми в програмному забезпеченні. Ось лише кілька: залежність класу в ООП від іншого класу; залежність бізнес логіки від GUI (чого бути не повинно) і навпаки; залежність системи від конкретної системи БД; залежність можливості виконання однієї вимоги від іншої вимоги, яка може її заперечувати. Здається, в програмуванні більше проблем із залежностями, ніж з розроблюванням алгоритмів.

Уміння виділити абстракцію. Це моя улюблена навичка. Я дуже тішуся, коли мені вдається виділити вдалу абстракцію в коді, і захоплююсь людьми, які вміють це робити. Річ у тім, що програмування – це цілковито абстрактна форма інженерії. Усі компоненти, що ми створюємо, є абстракціями і у фізичному світі не існують. Точнісінько як математика. Тому вміння вдало виділити абстракції і вдало їх організувати є ключовим для успішного програміста. (Не розумієш що я маю на увазі під абстракцією? Для прикладу, звичайна функція у процедурному програмуванні є процедурною абстракцією.)

Дитяча цікавість. Думаю, ця риса прямо таки критична. Людині постійно має бути цікаво “поколупати” то функцію, то фреймворк, то перевірити що буде якщо викликати функцію так і так. Якщо цю цікавість помножити на гарну пам’ять, отримуємо програміста, що за рік буде як риба в воді навіть у найскладнішій і заплутанішій системі.

Софт скіл. Той самий розмитий і малозрозумілий софт скіл. По суті це визнання того факту, що програмування-це суцільна комунікація. З комп’ютерами, через мову програмування, та з колегами різних спеціалізацій, через звичайну мову. Якщо так можна висловитися, це педагогічно-інженерна діяльність. До софт скілів також відносять вміння управляти своїм часом і організовувати свою роботу. Адже програміста важко проконтролювати та вказати коли і як йому працювати.

Посидючість, готовність тягнути рутину. Робота програміста в основному це сидіння перед монітором. Нерідко трапляються дні, коли немає жодної наради, і доводиться сидіти й фокусуватися 8 годин на день. Це не так складно, якщо завдання дуже цікаве, але не рідко трапляються нецікаві завдання, і тоді… важкувато. Щоб з усім цим впоратися, треба мати рису характеру, що дозволяє людині довго сидіти на одному місці в обстановці, яка не змінюється.

Уміння і бажання постійно вчитися. З точки зору навчання, ІТ одна з найвимогливіших галузей. Людина має постійно навчатися, щоб залишатся на плаву. Але далеко не кожна людина може це робити, якщо немає такої внутрішні потреби, такої риси характеру.

Уміння і бажання брати на себе відповідальність. Це не та риса, відсутність якої може стати show-stopper-ом для програміста. Людина може бути гарним програмістом, але не більше того. Ніякої технічної кар’єри на цьому вона не побудує. Коли ти відмовляєшся брати на себе відповідальність, тобі ніхто не захоче довірити важливий проект. А саме на важливих проектах людина росте як технічно, так і особистісно.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail