We will open that fridge when we get to itMeIr
All human systems are collections of human mistakesMeIr
I have been slowly teaching my kid a bit of programming. Programming is not easy, and teaching it to a child is quite a challenge, so anything that makes it easier is welcome.
Initially, I have been using Scratch to teach programming, however, I moved away from it because it is not really that easy to use once you want to make something a bit more complex (even I had some issues following online tutorials) or teach a kid about some programming concepts such as for-loops.
Next, I tried Swift Playground, it is awesome, however, I got stuck on explaining for-loops. It might be easy for grown-ups to get a grasp of syntax and associated concepts, but for a child, it is a challenge.
I have been thinking about what to do next. Python? Well, maybe it is a good direction, but again syntax will get in the way of learning programming concepts… Today, I discovered Hedy and it looks very promising.
Checkout GOTO2022 talk:
I chose this book among others because I wanted to get out of reading about programming, methodologies, and other related stuff. I wanted to read something more abstract, not necessarily applicable to my immediate work, and boy did I get what I bargained for.
Well, let me start with complaints. First and foremost, the book is a bit long. I feel like it could have been compressed a bit. No, there isn’t much fluff, just several chapters could have been reorganized. Second, and no less subjective, the book at some point turns into a “horror movie,” where each passing chapter, things get more dangerous, complicated, and helpless. But I have to admit, there is a certain charm to such a delivery. Last grumble of mine: few examples of highly scaled and/or distributed systems. I would love to see more examples and discussions about them. Now I know the grumble isn’t entirely fair, since I got what I wanted – “more abstract” – but by the end of the book, I was left wanting more. I guess appetite comes during a meal.
Now let’s flip the page and go in the opposite direction: the examples in the book are quite interesting and educational. I loved the discussion about Twitter’s design and a couple more along the way. I personally don’t work with databases or other data-related systems that much, so the author fascinated me quite a bit. Some discussions are quite lengthy and detailed, mostly due to the complexity of the subject, but that’s what makes them so good, opening up your mind to different ways of thinking about programs, structures, and networks. The “horror movie” comes and goes, it makes you doubt everything you took for granted, even a CPU’s ability to add two numbers together. The author seems to project a lot of paranoia, the levels are similar to the amount of paranoia exhibited by system administrators. It sure gives a lot of perspective to developers, since lots of things are assumed to work properly and not to fail at the most opportune moment. One last thing: as I was reading the book, it reminded me of a bit of fun I had reading research papers at university. Some of the design patterns did emerge from academia, and perhaps it is a good direction if you have an interest in it.
I believe the title speaks for itself. If you want to design data-intensive applications, the book might be a good start. Perhaps it will give you a good insight and/or wider perspective. But if you are looking for hands-on material, the book might disappoint you. It is hard to tell whether the book is worth it or not. I had fun reading it; I believe it is well written, and I can see that the author put a lot of work into it. So I’ll leave you with this: if you are curious about the subject, go for it!
In a nutshell:
+: Well written
+: Broadens horizons
+: Lots of discussions and examples
+: No requirement for specialized knowledge
-/+: In a way, a long book; in a way, it needs to be longer
=: If you have any interest in application design, the book is an awesome way to start your journey.
Title: Designing Data-Intensive Applications
Author: Martin Kleppmann
Just a blink of an eye and 2022 is gone. In the past few years, I was quite optimistic about the upcoming years, but this year finally broke my back… Covid, inflation, and finally war. I hate to sound like an old fart, but it’s getting harder to look optimistically into the future. I wonder if I’m just getting grumpier or if the world is making less and less sense – perhaps both are the same side of the same coin.
In any case, I’m happy that 2022 is finally over. I’m looking forward to 2023 and the victory of Ukraine. Perhaps after the war is over, the world will slow down just a bit and become a little boring for a while, giving us all time to catch our breath. I hope the economy will survive without going into a deep recession and that we can all just get a break. Well, at least I can dream and wish.
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
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.
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.