Speaking at People Team camp

I had the privilege to hold a web development workshop at the People Team summer camp. People Team is a fairly popular youth camp where participating kids choose some focus topic and attend to various lectures, workshops and activities during the week.

The topics range from learning languages, through arts, sciences, robotics, cooking, environmental protection to of course IT and programming. They are all pretty interesting, and for the last few years the IT HR company IseeQ has been responsible for organizing volunteering speakers and trainers for the IT focus topic – this is where I got into the picture.

via People Team Facebook


Of course I had a lot of questions, mostly the usual ones when you prepare with some training or presentation: what’s the topic? Who is the audience, their number, age group, skill level? How interested, involved are they going to be?

Most of these parameters were unknown or only partially known, basically, the training was for 11-17 year olds who are generally interested in IT but not necessarily have prior programming experience.

As title, I chose “Web development and security” – a popular topic. I wanted to introduce them into the world of the Internet that we use every day but probably don’t know what happens behind the curtains.

It’s not just about how HTML and JS works, because there is a lot more to the Web than just web programming.

How did the Web start out and how did it grow and evolve into what we see and experience today? What were its original goals and values, who used it? How does it work on a principal level? What are the most important topics, issues and controversies surrounding the state of the Internet and its usage today?

I think that these topics are especially important to the digital native generation, for whom being online is like water or air: they have never lived in a world without perpetually staying online.

I created a presentation draft in Joplin and some Codesandbox samples to tinker with in the browser. I decided not to make a classic Powerpoint presentation: it’s too much effort, and given the circumstances, I knew I’d likely have to improvise. Moreover, using a good old whiteboard or flip chart is more personal, credible and may even boost information retention (i.e. listeners will remember more).


After waking up early in the morning, finishing the outline and saving some supplementary images into a folder, I jumped on my trusty Kawasaki bike to make my way to the venue.

During the first part, which was the presentation about the Web itself, the participants were as involved as a group of random kids could be at 8:30 AM in a summer camp. Fortunately, good conversations emerged once we started unpacking more interesting topics such as cybersecurity and data protection. The audience seemed to be genuinely interested and hopefully are now eager to learn more about these important topics.

After a break, we moved into the computer lab, which was set up in a long and narrow corridor. This was the only way to ensure that everybody gets a computer to work on.

Unfortunately, the moment they opened their browsers, their attention level was seriously diminished. Just imagine the difference of effort between opening a code sandbox and starting to learn HTML, vs. opening your favorite game or just chatting. See…?

Nevertheless, after a short intro into what server-client architecture means and playing with the browser’s developer tools, we managed to create a few simple HTML pages linked to each other. Having no time for complex JS interactivity, we just maxed out what one could fit into an hour-long workshop.


  • If you don’t know your audience ahead of time, prepare with multiple scenarios. I haven’t used about a third of my presentation material (OSI layers turned out to be too advanced for this morning in a summer camp…)
  • Prepare for the worst circumstances – for me, this was not having a whiteboard and projector during the workshop session. I made a chat session, but it didn’t work out well – in hindsight, a screenshare could have worked better.
  • If the session is not a formal speech or lecture, not having a PPT presentation works just fine. You can easily lead the conversation and use a whiteboard to take notes.
  • In general, you’ll have less time than you think and less material to teach than planned.

All in all, this was an exciting experience for me as a lecturer. I enjoyed preparing for these workshops and giving back to the youth as a volunteer. I’m looking forward to repeating this next year, too!

Share this post

Does ‘software engineering’ even exist?

I’m not even sure if software engineering exists, or whether it should be called as such. See my opinionated post below.

How software emerged

As a reference, I have a ‘mechatronics engineering’ MSc, which is mostly a mix of electronics and mechanincal engineering. These classic engineering fields are called ‘engineering disciplines’.

Mechanical (and also civil) engineering is about 200 years old, electrical engineering is about 70-80. Whatever you’re designing, you’re leaning on the ‘shoulders of giants’, leveraging knowledge that may be more than a hundred years old.

Computer science has in fact branched from mathematics. In order to create computers and programming languages, we needed the computability notion of Turing completeness and the primal computer architecture (still holding today) envisioned by John Von Neumann.

Computer engineering, the practical side, kind of branched from electronics engineering, since software in first- and second-level programming languages were very close to the hardware.

You couldn’t just write an app in some high-level language, but rather needed to know a lot about low-level stuff like hardware architecture and CPU instructions.

Software gained huge traction in about 35 years ago, when personal computers became affordable, and embarked on a journey to eat the world. and now people call themselves ‘software engineers’. Heck, my employer calls me a software engineer!

Software engineering vs. hard sciences

Software engineering activities are similar to existing engineering practice in that you are modeling, measuring, researching and methodically refining a design in order to work towards some concrete end goal i.e. a software product. You can apply all the known engineering approaches and methods to design, implement, test and maintain software.

On the other hand, software engineering is totally different, much ‘softer’ (no pun intended) than mechanical, electrical, chemical or civil engineering that have something in common: they build on natural sciences.

In these classical disciplines, if you want to do something, you refer to some relevant physical or other scientific models, formulae, tables, standards whatever; get some results, maybe measure and simulate a bit and get a concrete result. Multiply by it some safety factor and there you go.

You can be sure because these standards and laws have been known for decades if not hundreds of years, they have been battle-tested in millions of applications. (Buildings, power and electronic systems, infrastructure, machinery, chemical processes etc.)

Compare this with software? Not so much. In that sense, it reminds me of non-natural sciences like social sciences or economics.

For each software problem to solve, you have 10 different languages, 100 frameworks, 20 totally different ‘paradigms’ with their own consultants, zealots and flamewars. Several could produce a satisfying solution to your problem, but they usually get replaced every 5 years.

Good old times?

5 years old software is called ‘legacy’, software that is 15 years old is often called a classic game or an anachronistic joke. Software expands like gas, taking up all available storage space and computing performance, but as time passes, in return we get many more layers of abstractions and a more complex development infrastructure. (Plus a nice UX, more ads and less privacy.)

We may think back of the ‘good old times’ when an operating system with several userspace software was able to run on e.g. a 233 MHz computer with 16 Mb of RAM (this was way after ‘640 kb was ought to be enough for anybody’). But we definitely don’t want to develop software the way it had been done back then, because we can create more, (maybe better) products, significantly faster.

As Uwe Friedrichsen puts it in his post about reusability:

…assume you need to build a not too challenging solution, e.g., a small e-commerce web shop that needs to run in a desktop browser and on mobile devices. If we leave aside for a moment that we can create such solutions today with tools like Shopify in a day or two, then this would be a task for a small team (5-7 persons) for 3-6 months.

But if you would need to start at the level of a bare programming language (3GL, turing-complete, no standard libraries, no ecosystem), this would be a daunting task: Probably a 100 or more people working for years, not knowing if they will succeed at all.

This enormous difference in productivity is the merit of reusability. If you needed string processing in C++ in the early 1990s, you needed to implement it yourself. Today, you start a whole HTTP server and more with a single line of code. This is reusability!

Uwe Friedrichsen, The reusability fallacy – Part 4

E for engineering, S for software

As we see, with classical engineering disciplines, the primary driver of progress was scientific research. Published in peer-reviewed journals, they meant a foundation for engineers to create well-documented and tested applications.

Software is changing much faster and it’s… well, soft.

  • We don’t have (natural) laws, we have ‘paradigms’ – one essentially never changes, the other apparently changes every few years.
  • We don’t have measurements, we have ‘metrics’ – we measure something but the goal is usually not to improve some model or control a system in a feedback loop, just to examine some system as it’s running, and restart it when it crashes…
  • We do have some standards (like ISO, ANSI), but compared to the speed of standards bodies, software is moving at a neck-breaking speed, and they are unable to catch up. Organizations like IETF and W3C represent ‘software standards’ much better, and work in a substantially different way.
  • We have some common terminology, but there is a lot of hype and buzzwords going around. The latest and greatest framework, architecture, language, paradigm, engineering method, whatever, promising easy and fast results. Of course.

Mother Nature doesn’t want to earn money on you when it comes to physical models. Consultants on the other hand do, when trying to sell their latest & greatest paradigms, ’10x’ engineering practices and lean methodologies.

Firms and managers can’t buy natural laws (though they do pay a lot to access ISO standards :)), but they love to rewrite their software into the latest and greatest architecture or framework, often without enough justification.

Summing up

What engineers/developers are doing may be similar to classical engineering practice but is way less exact. We may reason about programming languages, application architecture and business logic, but ‘clean coding’ practices and everyday ‘which library/framework should I use?’ questions are far from anything formal.

All in all, ‘software engineering’, although shows some similarities in approaching problems, is fundamentally different from existing classical engineering disciplines, changes much-much faster and probably we should come up with a better term for it, rather than abusing existing terminology.

I heard for example software craftsmanship… but I’m unsure.

What do you think about this?

Share this post

Self-taught software engineering: Coursera & co.

I really enjoy Coursera courses and have been doing them since I have been doing software engineering. It’s a great way to broaden my knowledge since I’ve never received formal computer science or software engineering education.

Just a quick update: I added a list of what I have completed to the About page.

Not really to brag; I guess one doesn’t spend countless hours at solving programming problems to just have a certificate to brag about. Okay, I’m fairly proud of these accomplishments, happily paid for the courses, and consider it time well spent.

Here’s a short post about what I have found out about these courses.

Share this post

My skills page is up!

Probably the longest self-description of one’s programming skills you’ve read in a while. Head right over there!

Share this post
Life Programming

Goals for 2020

It’s nice to have a list ready about what I would want to achieve this year. One is really ambitious of course, but this is something to refer back to later during the year, something to get inspired from in times of difficulty.

So here we go.

Share this post

Stress testing for “Data Structures and Algorithms” courses – Java & Python

I am doing the Data Structures And algorithms specialization on Coursera. (Which means every now and then I pick it up and make a few weeks of progress…) Started out with Python and now I’m switching to Java.

In this post I’ll show you how to set up stress testing, by generating random input data and comparing your implementation’s results to correct “naive algorithm” results.

I’ll also share a script that loads input from files and compares them to answers. This is useful for testing example inputs or pre-given tests for some exercises (usually where stress testing is not feasible)

Moreover, there is a GitHub repo with the ready-to-use solution.

Share this post

My Java experience as a Javascript developer

Motivation – why learn Java as a JS dev?

As a software engineer for about 2 years, I learned a lot. Starting out as a Typescript/Node.js developer, I quickly got the gripes of the Javascript world.

As we know, Javascript is a dynamically typed language, with an ‘objects linked to other objects’ (or prototype linking) approach. ES2015 adds some class-like syntax sugar on top which I personally don’t like, but frameworks such as Angular really embrace them.

Typescript adds static, compile-time type checking to the picture with a neatly engineered type system but it ultimately has no effect during run-time (apart from juggling with source maps).

I think that if as a developer you specialize in one or two languages, it’s still important to learn other languages, too, to widen your views and better understand general programming principles.

I believe general understanding turns you into a better engineer even if you don’t have a CS degree, plus it helps you pick up other tools of the trade (languages, frameworks) easier during your career.

Share this post


My first blog post. If you are reading this, welcome! I’m happy that you are here.

I’m Gergely (Greg), a software engineer from Budapest, Hungary, who loves solving problems while at work (anywhere it catches me), hacking at home and boxing at the dojo. 😉


I decided to start a blog for multiple reasons:

  • Get stuff out of my head i.e. share useful information
  • Reflect on my journey as a professional software engineer
  • Connect with people
  • Find my own style and practice writing
  • Have my personal corner of the internet, aligning with my values about how the web should look like despite being an active developer of the modern web. 🙂

Expect posts every now and then, once a week by the least.

Upcoming stuff

Well, for starters:

  • A proper contact area
  • Add a photo of myself?
  • Expand the About page a bit with my personal creed
  • Create a skills list & roadmap to share my learning journey
  • Reflect on my current career goals and general experience as an enterprise employee

What now? Feel free to say hi in the comments and subscribe to my RSS feed. Sorry, no mailing list this time, but let me know if you would prefer an email notification.

Share this post