diff options
Diffstat (limited to 'content/posts')
| -rw-r--r-- | content/posts/coders-at-work.md | 31 | ||||
| -rw-r--r-- | content/posts/critical-cs.md | 10 | ||||
| -rw-r--r-- | content/posts/denounce-ai.md | 2 | ||||
| -rw-r--r-- | content/posts/dijkstra-knuth.md | 6 | ||||
| -rw-r--r-- | content/posts/mythical-man-month.md | 16 | ||||
| -rw-r--r-- | content/posts/poster-fair.md | 15 | ||||
| -rw-r--r-- | content/posts/thinking-fast-and-slow.md | 7 |
7 files changed, 32 insertions, 55 deletions
diff --git a/content/posts/coders-at-work.md b/content/posts/coders-at-work.md deleted file mode 100644 index d143553..0000000 --- a/content/posts/coders-at-work.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Coders at Work" -date: 2025-12-28T18:46:07+01:00 -draft: true ---- - -_Coders at Work_ by Peter Seibel is a great book which I recommend everyone read. -It relates the experience and learning journey of some of the best programmers of all time, and gives precious insights into their work -- what drove them to become great, what they think is important when programming, and what are their visions for the future. -These 3 subjects together with answers corroborated from all interviewees form guidelines on how one can become a great programmer themself. -Here is what I think about each chapter and person. - -1. *Jamie Zawinski* - -Jamie Zawinski currently owns a nightclub in San Francisco, the [DNA Lounge](https://www.dnalounge.com/) (imagine how cool this is) and he does not do much programming nowadays as he used to. -Nevertheless, he began work on Netscape which later evolved into Mozilla Firefox. -Jamie is a person that has a very outspoken political views and opinions about certain things, which you can read about on his great blog [www.jwz.org](https://jwz.org/). -I both agree with him on many current worldwide issues and admire him for his past contributions. - -2. *Brad Fitzpatrick* - - -3. *Douglas Crockford* - - -4. *Brendan Eich* - - -5. *Joshua Bloch* - - -6. *Joe Armstrong* diff --git a/content/posts/critical-cs.md b/content/posts/critical-cs.md index c7f57f7..373da9c 100644 --- a/content/posts/critical-cs.md +++ b/content/posts/critical-cs.md @@ -10,13 +10,13 @@ What might come off as even more unexpected, is that I agree with the points the It begins with the example of Elizabeth Holmes and the well-known Theranos fraud. Having actually been fairly recently sentenced to 14 years of prison for her crimes, such an example is no way to optimistically end a book. -But it shortly highlights a recurring problem: _rapid improvements in computer technology had not led to proportionally great social advances or economic developments_. +But it shortly highlights a recurring problem: _[...] rapid improvements in computer technology had not led to proportionally great social advances or economic developments._ Ceruzzi and Haigh are entirely right. On top of this, they provide several more examples, including, quote: _From 2008 and 2018, productivity growth in the US averaged just 1.3 percent a year, well below the 2.7 percent achieved from 2000 to 2007._ While I disagree with the authors on the impact of the computer on society, their comments on negative consequences of the computer on our daily lives are straight on point. _The typical American worker of 2018 was no better paid, after adjusting for inflation, than the typical American worker of the 70s._ It's pretty hard to argue with such a statement. -In short, both authors conclude that technology does not benefit the ordinary man, but only the so-called "top 0.1\%", _whose income after tax quintupled from 1980 to 2018_. +In short, both authors conclude that technology does not benefit the ordinary man, but only the so-called "top 0.1\%", whose income after tax quintupled from 1980 to 2018. Needless to say, the rest of the chapter is narrated in a similar tone. But to more deeply reflect on its relevance to my own personal experiences, I'll try to connect it to the recent workshop I participated in at my university. @@ -33,7 +33,7 @@ Firstly, my attention was immediately grabbed to my classmates behaviour when th With roughly 40 people in the classroom, including the staff members, the very moment the first video was played, every single person, with no exception averted their attention towards the projector. It was like a scene from a sci-fi horror movie -- one moment everyone was talking over each other, and in the next all 40 heads in the classroom went quiet and synchronously turned towards the single big screen. Nobody made a single sound for the terrifying 3 minutes it took to play those videos, which for me seemed like an eternity. -This event reminded me of George Orwell's _1984_ and the recurring theme of screens in the book for propaganda purposes and the surveillance of book's population. +This event reminded me of George Orwell's 1984 and the recurring theme of screens in the book for propaganda purposes and the surveillance of book's population. I think the parallel is hard to miss. Afterwards, we were given as a team a task to create such a video promoting a randomly selected chocolate protein bar. @@ -42,8 +42,8 @@ The outcome was a 1 minute TikTok promoting a protein bar not a single in person This is precisely why at this point it crossed the line for me and I refused to actively engage anymore in the workshop. The techniques we were advised to use to improve our video exploited the low attention span of the viewers. -A _hook_ -- that's how the first 5 second, attention-grabbing stop-motion of the TikTok was described to us. -As such, my team successfully _hooked_ the audience (classmates) by video advertising a product which they had practically zero idea about. +A "hook" -- that's how the first 5 second, attention-grabbing stop-motion of the TikTok was described to us. +As such, my team successfully hooked the audience (classmates) by video advertising a product which they had practically zero idea about. To top it off, I took the courtesy to read its nutritional value afterwards, which for e.g., included palm oil, responsible for the hundreds of thousands of acres of deforestation in the Amazon. With no concern or afterthought about the potential impact of our advertisement, my team mates submitted the video to a shared, available-for-all Google Drive. diff --git a/content/posts/denounce-ai.md b/content/posts/denounce-ai.md index 03c2b98..6d0da91 100644 --- a/content/posts/denounce-ai.md +++ b/content/posts/denounce-ai.md @@ -36,6 +36,6 @@ I will not raise the ethics concerns behind such actions, it's also not my aim t However, I think the question above is worth asking to yourself. I think the point made by [Hayao Miyazaki](https://en.wikipedia.org/wiki/Hayao_Miyazaki), the studio Ghibli founder behind some of the best animated movies of the last century summarizes it pretty well. -Recently there has been a viral video going on of him saying in 2016 how he believes AI to be _an insult to life itself_. +Recently there has been a viral video going on of him saying in 2016 how he believes AI to be "an insult to life itself". As strong of an opinion as it is, I sympathize with his standpoint of view. Being an artist and designer, seeing your life's work being completely overtaken by soulless software must be terrifying. diff --git a/content/posts/dijkstra-knuth.md b/content/posts/dijkstra-knuth.md index ca73407..a284a1e 100644 --- a/content/posts/dijkstra-knuth.md +++ b/content/posts/dijkstra-knuth.md @@ -10,7 +10,7 @@ I believe it to be the most important thing I have learned about the field itsel Here is why. Dealing with complex problems is hard. Programming is all about solving complex problems, programmers live by optimizing our code the best we can, and try to find solutions to problems that we encounter while doing so. -While it is no doubt nice to have a working code that does something cool, or a solution to a problem that meets the specification, I don't think that is the mindset a programmer should have -- that is, at this stage, to solve a problem is not about getting to a solution _somehow_. +While it is no doubt nice to have a working code that does something cool, or a solution to a problem that meets the specification, I don't think that is the mindset a programmer should have -- that is, at this stage, to solve a problem is not about getting to a solution somehow. Solving coding tasks requires time. This might be difficult to admit for some, as it has been for me. @@ -19,7 +19,7 @@ Needless to say, if you have solved a problem without asking questions about it, Reading code is hard. It's sometimes like reading an essay in a foreign language. Your head hurts, your eyes are getting sore, and after 6 hours of staring at the screen you conclude you don't understand anything anymore. -One of my favourite quotes about computing from Temple OS creator, [Terry Davis](https://en.wikipedia.org/wiki/Terry_A._Davis), reflects this perfectly (it's too long to include here, so [this is the link to the GoodReads quote page](https://www.goodreads.com/quotes/10916333-what-s-reality-i-don-t-know-when-my-bird-was-looking)). +One of my favourite quotes about computing from Temple OS creator, [Terry Davis](https://en.wikipedia.org/wiki/Terry_A._Davis), reflects this perfectly _What’s reality? I don’t know. When my bird was looking at my computer monitor I thought, ‘That bird has no idea what he’s looking at.’ And yet what does the bird do? Does he panic? No, he can’t really panic, he just does the best he can. Is he able to live in a world where he’s so ignorant? Well, he doesn’t really have a choice. The bird is okay even though he doesn’t understand the world. You’re that bird looking at the monitor, and you’re thinking to yourself, ‘I can figure this out.’ Maybe you have some bird ideas. Maybe that’s the best you can do._ It would almost seem like this time has been wasted, since you might have not produced a line of code. Nevertheless, this is all there is to programming. @@ -30,6 +30,6 @@ There it is. Computing takes time. There's no silver bullet yet, and we as programmers have to take our time to think about problems in depth. There have been many comments on the peculiar style of teaching and way of being of Edsgar Dijkstra, but I believe he has made some really good points about this too. -What describes my experience over the last 3 years well is his quote: _The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility[...]_. +What describes my experience over the last 3 years well is his quote: _The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility[...]._ I think this the approach to take, because so often computers help us verify and point out that we indeed really don't know anything, we are just pretending we do. diff --git a/content/posts/mythical-man-month.md b/content/posts/mythical-man-month.md index 2849e12..b4952ef 100644 --- a/content/posts/mythical-man-month.md +++ b/content/posts/mythical-man-month.md @@ -4,31 +4,31 @@ date: 2025-12-22T17:25:54+01:00 draft: false --- -_The Mythical Man-Month_ by Frederick. P. Brooks is a book about his experience during development of OS/360. +"The Mythical Man-Month" by Frederick. P. Brooks is a book about his experience during development of OS/360. It was recommended to me by my honors project supervisor, Prof. Alexandru, but even without his recommendation I would have likely stumbled upon this book. Its contents are hailed as timelessly relevant and some of the most universal truths about working on coding projects are described inside. While I admit I don't get all of the books many premises, some of them really speak to me. Taking after the opening of the 18th chapter of the book: _For brevity is very good, whether we are, or are not understood_ I wil go through some of it's premises and try to relate them to my own experiences. -Perhaps the most well-known theorem is Brook's Law: _Adding people to a late project will make it even later_. +Perhaps the most well-known theorem is Brook's Law: _Adding people to a late project will make it even later._ This is exactly right -- it is indeed the communication overhead, the time needed for new members to comprehend the already existing codebase, and the difficulty of rejecting the new colleagues ideas on how to improve things that contribute to making the project later even more. Compared to, for example, the construction industry this is a stunningly unexpected discovery. It goes against everyone's best intuition, including mine. -While on the topic of construction, Brooks admits in the 20th Anniversary Edition of the book (the one I read), that his approach -- _build one to throw one away_ is now obsolete. -According to him, the right approach is to _grow_, not build software. +While on the topic of construction, Brooks admits in the 20th Anniversary Edition of the book (the one I read), that his approach -- build one to throw one away is now obsolete. +According to him, the right approach is to grow, not build software. I also agree with this. It is so much easier to design a system like this, rather than try to fit into one's mind everything beforehand, expecting all things to work if we just conceptually figure out everything first. -This is not to be mistaken with the fact that majority of programmer's work is inside their heads only -- this is the _essence_ of programming which Brooks talks about. +This is not to be mistaken with the fact that majority of programmer's work is inside their heads only -- this is the essence of programming which Brooks talks about. -_No Silver Bullet_ is one of the added chapters of the book, which was missing in the original edition. +"No Silver Bullet" is one of the added chapters of the book, which was missing in the original edition. It conveys a premise that I think is the most important thing that I have learned from this book. That is -- we cannot change the essence of programming, and for foreseeable years and decades to come, the struggle of the ordinary programmer will always be figuring out solutions to a problem within one's mind. No amount of abstraction, colorful IDEs and integrations, or pretty UI interfaces with hints and AI toolkits will overcome the fundamental truth about programming -- our work has no physical counterpart in the real world, just like mathematical equations do not. A mathematician may solve the equation on paper, but it is the thinking inside one's head that produces the solution, unlike a painter who's art is immediately visible on the first brush stroke and is the goal and final product of the work. -_The Mythical Man-Month_ also gives me a clear goal to look forward to. -Brooks states: _Very good professional programmers are_ ten times _as productive as poor ones, at the same training and experience level_. +"The Mythical Man-Month" also gives me a clear goal to look forward to. +Brooks states: _Very good professional programmers are ten times as productive as poor ones, at the same training and experience level._ Reading this reminded me of a friend of mine who also mentioned to me once that his goal is to become a 10X developer -- a person who is able to do the work of 10 ordinary programmers. I think this is a grand goal to work towards, certainly I would feel happy achieving. diff --git a/content/posts/poster-fair.md b/content/posts/poster-fair.md new file mode 100644 index 0000000..ca719c1 --- /dev/null +++ b/content/posts/poster-fair.md @@ -0,0 +1,15 @@ +--- +title: "HP Poster Fair 2024/2025" +date: 2026-02-08T15:38:10+01:00 +draft: true +--- + +Last year we in June I presented my poster during the annual HP Poster Fair at the VU. +Here are the photos and my poster: + + + + + + + diff --git a/content/posts/thinking-fast-and-slow.md b/content/posts/thinking-fast-and-slow.md deleted file mode 100644 index dfe010f..0000000 --- a/content/posts/thinking-fast-and-slow.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "Thinking Fast and Slow" -date: 2026-02-02T17:25:36+01:00 -draft: true ---- - - |