Even children’s program must participate in Russian war.
I been developing software for a while now and managed to read few books on the subject. Some books are general purpose, some with narrow focus on a particular subject in the development process. Pragmatic programmer is general purpose book on the subject.
I picked up the book in hopes of learning something new, something I haven’t seen or read before. Surprising enough I did find few things, but not nearly enough to justify going through the entire book. Now let me be very clear, the book itself is a good book, if you are starting out and want to improve your skills and understand what’s out there. However it might be a waste of time if you been in the game for a while and read a few things here and there. Also I can’t help but notice that some topics are not well covered even at a basic level (IMHO).
Since negatives are largely based on the amount of knowledge/experience a developer has, let’s talk about positives. The book is well written and relatively short. There is no fluff or metaphysical discussions, just practical and pragmatic advice. The book outlines and talks about all the useful basics that each developer should have, like: structures, clean code, testing, design, refactor, thought processes, personal & team behaviour, project organization and development methodologies. There is no deep dive into any subject, just essentials – which should spark enough interest in a developer to start researching more on any particular subject of interest. The author’s personal experience also comes in handy, some things don’t change over decades.
Overall, the book is good for inexperienced developers and for the experienced developers this book might be a trip down memory lane.
In a nutshell:
+: Well written & short
+: All the basics
+: Some hands-on examples
-: Some subjects are not well covered even at basic level
=: Good book for new developers, but not much value for experienced devs.
Title: The Pragmatic Programmer, 20th Anniversary Edition your journey to mastery
Authors: Andy Hunt, David Thomas
Ukraine is fighting for 7 months now
Couple of days ago, putler announced “partial mobilization” of 300 thousand men. In reality it is a full mobilization and numbers looking towards a million. It is not a good news for Ukraine, but let’s not forget, at the beginning of the war, situation was much worse.
As I was thinking about the mobilization, I decided to find a trailer for a documentary and it brought back memories of how fearlessly and courageously Ukrainians fought and continuing to fight. Mobilization will not help putler, it will not save anyone or anything, just one more stop on the way to hell.
5 topics for yearly knowledge refresh
Recently one more senior developer decided to leave my team and the company. The event got me a bit sad, not only the team is loosing a good developer but it also means new developer will be joining the team and that means teaching the developer all the ropes.
I have been through this few times now and its really starting to get to me. It takes time for a developer to learn how to write clean code, test drive, refactor, not to mention learn all the ins and outs of the company’s systems.
In addition I keep noticing that a developer can take expensive courses, lets say on TDD and still lag behind – missing tests or writing too many. That got me thinking, is it possible to improve the situation by creating yearly refresh courses? Effectively new developers get to know all the essentials of development at the company and present developers get to fresh up on the existing practices and perhaps come up with improvements (or trash something that no longer brings value).
So here are 5 topics:
- Clean code
It is important to learn and practice writing clean, easy to read and follow code. Clean code is a foundational knowledge, it effect all other practices in very fundamental way (from production to test code).
- Unit testing and TDD
Testing is the prerequisite for continues delivery. Every developer must understand the value of testing and how it enables continues delivery. TDD is the best developer technique for writing valuable tests with the maximum reasonable coverage. Tests is code, it requires maintenance, tests must bring value and TDD is well established technique for doing so.
No one ever designs or writes perfect code. Moreover no one has crystal ball that predicts future business needs. Refactoring is important skill for continuously changing, adopting and improving code and system design.
- Higher order testing
Beyond a system boundary, there are more systems. Developer must understand techniques and tools that are available for Integration, Contract and E2E Testing. Pros and cons must be weighted carefully in order to provide meaningful automated testing and short lead times.
- Pipeline and environment
Software systems no longer built locally and run on bare metal. Pipeline builds systems and those systems run in virtual environments. While developers are not DevOps (and probably will never be), it is important for developers to know how pipelines are developed, employed and maintained. How systems are packaged and run in docker under Kubernetes.
Over last nearly three months we’ve been hosting refugees. Perhaps it is a noble cause, may be admirable but we did it because it seemed as the right thing to do – people needed help and I and my wife were in a good position to help. I believe it is the biggest selfless act we performed to date. But I’m not writing this to brag, I’m writing this because I’m deeply sad and somewhat mentally struggling to process the past three months.
Let me start by stating somewhat fascinating (at least to me) fact; in the last three months, I learned nearly nothing about these people. All the time it felt like they didn’t want to be bothered. After initial few of attempts by me and my wife, we frankly gave up. It felt like they were ignoring us as much as possible. Most of the time we walked into a common area, they would leave (even though we encouraged the use of common area). Efforts to socialize were made but ultimately failed. We still talked but mostly when they needed something: taking to places, food, documents, resume and stuff like that. Granted, our family is having hard time with traditional breakfast/lunch/dinner – we simply don’t have “get together and eat”. But once in a while we do, at one point we got together for Chinese food dinner and invited the refugees. Kids (age 8 & 12) didn’t bother joining and their mom joined but the conversation didn’t really take off, as soon as food was done she left to her room and closed the door.
The kids are fascinating, simply because I never encountered such behaviour before. They never said “good morning”, unless I said “good morning” to them first. Forget about “good night”, may be “thank you” couple of times. I never met such a shy/private kids before. I remember meeting a super geeky boy a while back, but even though he was super shy, he still seemed pretty happy to be noticed and talked to. In this case kids seemed to regard me as necessary evil (at least that’s the way I felt), unhappy about any conversation attempts and never wanting anything. I never met any less curious kids in my entire life. Whenever I attempted to offer anything, they would immediately say “no”, in some cases even before I managed to finish a sentence. I have a six year old and it seems she received exactly the same treatment after initial several days of hanging out with the refugees. I know older kids don’t always like to hanging out with younger ones. But total ignore? It was painful and somewhat fascinating to watch my kid, she seemed to figure it out on her own and after sometime didn’t even notice the refugees.
I don’t know if we offended them in any way, I keep thinking about it but it’s not like we had extended conversations or discussions about anything. Most of the time they just stayed in their room, the door closed and didn’t communicate with us. We helped as much as we could – as much as I wish my family had received in a similar situation. We bought their airplane tickets, beds, food, clothing (some used, some brand new), helped with paperwork, provided a car to practice driving, pickup from the airport (which is 4 hours away), introduced to some people we knew and my mom somehow managed to get summer camp for the kids free of charge (typically about $300 per week per kid) – thank you city hall! Yet as time rolled on, we all got a feeling that we were bothering them, my wife mentioned that we were given the “cold shoulder”.
After nearly three months, one day, as I was making a tea in the kitchen, the refugee lady came out of the room and told me that she needs help – a ride to Brampton. I wasn’t sure if I wanted to spend my weekend driving refugees 4 hours away and then returning home. Despite advice of everyone (who knew what’s happening), I decided to drive the refugees to Brampton, to make sure they got from my place to their destination safely. As the day of departure approached, I was tensing up, I thought to myself: surely, the refugees will at the very least come out the room and say “thank you” and “goodbye”. I didn’t expect a dinner or tea or cookies, I mean after spending so much time avoiding us, I really didn’t expect much, no hugs, just a simple old “thank you”. My wife chuckled at me and gave me a new name: “Eugenius Simpletonius Maximus”, implying that I’m kindly naive. My mom simply said: “you will receive no gratitude”. Friend of mine said: “she will not thank you” and added that I’m hopeless optimist, yet, I still believed in basic human gratitude. The final evening came and went, my mom received no thanks even though both of them were home all day long. Me and my wife came home in the evening, the door remained shut with light inside – no thanks or goodbye came to us either. I got deeply upset.
Early morning the refugee lady asked for help – to take luggage to the car. So I did, I had a nut in my stomach, I briefly considered driving them to the nearest train station and leaving them there, but decided against it. So we drove for 4 hours towards destination in complete and utter silence. I still could not believe what had happened and I definitely didn’t know what to say, I was in complete and utter shock, the lady made no attempt to talk to me or even look at me the whole drive. The final moments were memorable, as we arrived, I unloaded the car, looked at the lady – she was busy with her kids, I walked to the car, looked at her again, she was still not looking at me, I sat into the car, still no attention to me, I started the engine – she didn’t even turn around and I drove off. I didn’t wait around, figuring everyone else was right at the end of the day and I was dead wrong.
45 minutes after I drove off, the lady decided to send “thank you” emails to my mom and to my wife, an email, after nearly three month of stay and all the help, we got an email! At this point I didn’t argue with my wife when she said “she is not done with us, she needs something from us” and she was dead right once again.
P.S: I’m still deeply upset, I know it will pass… but I’m still having a hard time comprehending the last three months.
Crying in the beer
I’ve sat through far too many “crying in the beer” sessions where all the energy for change was dissipated in the intensity of the complaining. Once you see an idea for improvement that makes sense to you, do it.Kent Beck, Extreme Programming Explained: Embrace Change
Установка видеорегистратора в Mazda NC Miata
Premature optimization, value and waste
Ah, premature optimization, every developer sooner or later hits that. You optimize code, iron it out so there are no extra cycles, no extra memory or what not and not terribly long after you have to take that carefully tailored code apart, just because a new requirement came in. Worse yet, the realization that the optimization was useless in the grand scheme of the app, yes the app works more efficiently but it does not affect anything at all. Some might be proud of the craftsmanship, others might be disappointed with the waste, in any case I’m not here to judge.
I am here to share a story about premature optimization but at a much higher level – a feature level. A few years back when I started writing my app I wanted it to have a feature, let’s call it “frequency determinator”- feed data to the app and it can determine how often an event occurs. In my mind, it was very cool to feed the app data and automagically determine a pattern. Well, I started with the determinator code, it was simple but working. I said “great, it is time to apply it to real data that I have”. But there was a problem, I didn’t have an app, it was just code for frequency generation, I would like to be able to upload data from my phone and see the magic. Ok, no problem, I thought to myself, I just need an UI. I wrote first version of UI, which looked very basic and was incredibly confusing to use at times even to myself. So I rewrote it, added few features, just so the app can be a bit more useful to me. I thought to myself: “well, now that I have UI would it nice to have this and that, I’ll hook up frequency determinator in next little while”. I showed my app to a friend but UI was still confusing. Ok, no problem, I rewrote it again and added more features. Since I already had some data in the app, it was becoming more and more useful. Along the way I did some more refactoring, added just few more features, changed the UI a couple more times and the app was shaping up more and more. I was happy, the app alleviate big chunk of my anxiety and with each new feature, it was becoming more valuable and refined.
Is it there yet? Nope, I still need to rewrite the UI, since there is lot of room for improvement in usability. I can definitely use couple more features and some additional features that I believe can reduce some of my anxiety. So when is “frequency determinator” coming in? I don’t know! As I was using the app, refactoring and adding features, I gradually realized that time for “frequency determinator” hasn’t come yet. There is no need and from the feedback I got, it might not be ever needed. Something that looked like great feature, a centre piece of the jewel, turns out otherwise. Once you use the app, you realize where the value is for you. Once others use the app, you see move value around. The value doesn’t exist in vacuum of your own ideas, value only exists when someone points to it.
So, what now, stop wasting time and start looking for value? I wish I can say that but in reality my ideas of “frequency determinator” kicked started initial development. I might not have started writing the app without believe that “frequency determinator” will be the key to solving my problems. So is there a value in a waste? I believe there is, we “waste time” but because of it, we come up with ideas. I think wasting time looking at the sky or laying around on the coach is actually a good thing. But nothing will come out of waste alone, entertain ideas enough, build something, use it and see if the value is there for you.
Midnight in Chernobyl
I don’t have any particular curiosity towards soviet or post-soviet history. I watched the HBO mini-series “Chernobyl” and “Chernobyl The Lost Tapes” documentary, so I got enough of an idea about what happened. Since I was born in Russia and spent good chunk of my life there, I don’t need to be explained about corruption, incompetence and the Soviet ways.
So how did I end up with the book? I have a Canadian friend, really sharp guy, reads books, thinks things through, really fun to talk to. Many years ago, yet another regular conversation took a turn towards the topic of corruption in Canada. Before long he made a broad statement: “… it is the same in Russia”. I disagreed and he disagreed with my disagreement. This was the first time when I realized that people in Canada and in the west, don’t really understand Russia, more specifically that there is a difference between corruption and Russian corruption. In nutshell it is like comparing teenage hockey and professional hockey. Not long ago, my friend, came back to the subject of corruption, but now with a totally different position, now he no longer disagreed with me. I was surprised and he elaborated on his revelation – “Midnight in Chernobyl”, insisting that I should read the book as well.
So how is the book? Well, without a doubt the book is good, very good. It is well written and can be gulped without breaks. What you don’t find in any show or movie is nitty-gritty details and the book does a lot of justice to that. You can feel and see the system at work, incompetence, secrecy, economic and social struggle in “full HD color”. I believe the book represents a relative short and concise case study of the Soviet Union and how people though, operated and sacrificed. To some degree you will be able to understand even current situation and decision making of Russia today (including Russian invasion of Ukraine). The book is about Chernobyl, it is about the tragedy but Chernobyl story spans way beyond boundary of one location and far across entire USSR.
In a nutshell:
+: Well written & easy read
+: Lots of details
+: Brief history of soviet reactor building
+: Great insight into how the state operated
+: Overview how people lived, all equal but some are more equal than others
=: It is a good book, if you have any interest in historic events, pick it up. Chernobyl is one of the greatest disasters and perhaps it is worth while to learn about it, at the very least for the sake of not repeating it.
Title: Midnight in Chernobyl: The Untold Story of the World’s Greatest Nuclear Disaster
Author: Adam Higginbotham