Tech Leader Pro John Collins

We lost the spirit of Web 1.0, can we ever revive that via a Neo Web 1.0 renaissance?


Notes:



I am back!
It may be sentimentality, but I really miss the old days of the internet.
I remember using it for the first time in a public library on a 56k modem, on a PC that you had to book in advance.
There was an excitement about it, it was new and unexplored.
Bandwidth was such an issue, online video was practically non-existent, while images loading in via progressive scans, initially as low-resolution images that gradually became clear over several seconds.
Social media did not exist.
Search engines had no ads.
There were no pop-ups for accepting cookies or signing up to newsletters.
Instead, we had personal home pages with page counters, blink tags, and scrolling marquees, and web rings...
E-commerce did not exist, I can clearly remember when people we paranoid about sharing their credit card details online with anyone for fear of being ripped off.
They had to be educated to "look out for the lock" for SSL-enabled websites before sharing their credit card details.
To think there is a whole generation of Zoomers who never experienced the naive joy and freedom of Web 1.0.
Do we need a Neo Web 1.0, a return to the old?
There was an attempt to do something similar a few years, back, when Geocities relaunched as Neocities: "Neocities is a social network of 685,600 web sites that are bringing back the lost individual creativity of the web." - https://neocities.org/
I love projects like Neocities, and launched Greppr for similar reasons.
As a technologist, I will never advocate for a return to the past, but in the shift to the commercial platform dominated internet we have today, we have really lost that free spirit of discovery and hacker ethos.
An internet of builders and hackers is far more interesting that an internet of consumers.
We have arrived at the wrong destination.
What I am working on this week:


Greppr.org - Now at 2.8m web pages indexed.

Media I am enjoying this week:


For All Mankind.
Cyberpunk 2077.



Notes and subscription links are here: https://techleader.pro/a/621-Tech-Leader-Pro-podcast-2023-week-47,-Neo-Web-1.0

The more legacy code your team maintains, the greater the impact on their productivity. Legacy code is a tax, and should be deleted when possible.


Notes:



Organisations often approach legacy applications with a sense of fear.
Throughout my career, I have seen legacy applications, or legacy sub-systems of an application that contain some code that nobody left in the organisation understands.
I have even seen Cobol applications running on mainframes for 20-30 years, that are well beyond End-Of-Life (EOL), and yet somehow they still "just work" and nobody wants to switch them off.
You should delete that code.
The reasons for this are simple:


Legacy code is a tax. You need to pay to maintain it, and pay an opportunity cost for any resources or thought you need to waste on it.
Code that exists in your team that nobody is willing to work on is literally unmaintainable.
Tech that stands still in time is dead tech. It is your job to kill it.
Less is more. The smaller the code base your team needs to maintain, the more efficient they will be due to less legacy tax.

If we take the approach of "commit or cancel", we should either fully commit to maintaining an application in production, or cancel it. There should be no halfway, somewhat working, somewhat broken state.
One useful approach that a team can take to deal with legacy applications is the Strangler Pattern, which is defined as follows on the Redhat site:
"The Strangler pattern is one in which an “old” system is put behind an intermediary facade. Then, over time external replacement services for the old system are added behind the facade.
The facade represents the functional entry points to the existing system. Calls to the old system pass through the facade. Behind the scenes, services within the old system are refactored into a new set of services. Once a new service is operational, the intermediary facade is modified to route calls that used to go to the service on the old system to the new service. Eventually, the services in the old system get "strangled" in favour of the new services.".
Ref: https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern
That pattern can help settle nerves, by enabling the organisation to run in parallel the legacy application and the new service that will replace it over time.
All legacy applications or sub-systems should have a modernisation plan ("commit") or a decommission plan ("cancel").
Just leaving the lights on is never enough: hope is not a strategy.
What I am working on this week:


New blog "Decline is a step down process" - https://techleader.pro/a/619-Decline-is-a-step-down-process
New video formats on Youtube: more visual thanks to stock photos and videos.

Media I am enjoying this week:


Diaspora by Greg Egan.
Caesar by Christian Meier.



Notes and subscription links are here: https://techleader.pro/a/620-Tech-Leader-Pro-podcast-2023-week-42,-delete-your-code

As a leader, you need to think about how you react when things go wrong. Your example matters.


Notes:



In the software industry, bugs are a fact of life.
In complex systems that exist in complex environments, things can and will go wrong.
As a leader, you need to think about how you react when things go wrong.
An ex-manager of mine, who was a brilliant mentor, used to say: "John just present the facts and you can't go too far wrong. Don't get emotional."
As a leader, if you panic then others around you will panic, and you are calm they will be calm. You have influence, and your example matters.
In terms of a high-level process you can apply:


Don't communicate anything until you know the facts, and tell your team the same. It just adds confusion if you communicate unproven facts too early.
Choose a small team of experts, and task them to find the facts. Stay close to them.
When the experts reach a conclusion, you as their leader summarize that, and then get them to review it for accuracy.
Finally, you communicate the facts of what happened, how it happened, impacts, and actions to the stakeholders.

In general, engineers are not great at communicating because:


They communicate "work in progress" findings too early, some of which will be false signals.
They communicate too much detail.
They go too deep on the technical details.
-Your job as a leader is to be a world-class communicator: you need to take the raw facts from the engineers, and package that into a crisp summary that anyone in your organization can understand.

What I am working on this week:


Greppr.org - the Apache Nutch indexer is now a lot more stable since I added a lot more storage. It's slow, but stable. Now at 2.7m web pages indexed.

Media I am enjoying this week:


Diaspora by Greg Egan.
Caesar by Christian Meier.



Notes and subscription links are here: https://techleader.pro/a/618-Tech-Leader-Pro-podcast-2023-week-41,-staying-calm-under-pressure

At times like this, I hate social media: the ugly side of many people starts to show via this brutally honest mirror.


Notes:



The world is a bit crazy right now, with all of the ongoing wars.
At times like this I hate social media: the ugly side of many people starts to show via this brutally honest mirror we all carry around in our pockets.
My X feed this week was not only full of horrific videos, but lots of hateful, divided commentary.
Tribalism enables many people to justify any kind of behaviour, not matter how horrific. Empathy is lost.
Equally disturbing is the so-called "hot take guys", who want to comment on whatever is trending on X that day.
When I see people jumping on trending topics just to get some views, no matter how tragic those events are in real life: I find that disgusting.
I wish we had a site like X that only focused on economics, business, tech, and science only, but the truth is that all of those topics are now being looked upon via a Left or Right prism. Bias is everywhere.
I am apolitical, I vote for nobody, but I must admit I am in a tiny minority.
The best thing I can do is drop off social media until the latest storm passes, or drop off social media altogether...
In its normal state, social media is noisy. In an abnormal state, it becomes overwhelming: a series of angry mobs shouting at anyone who dares to disagree.
What I am working on this week:


Five.Today - there was a bug that impacted upon recurring daily/weekly/monthly tasks, resulting in them not being created properly. I have fixed this bug today.

Media I am enjoying this week:


Diaspora by Greg Egan.



Notes and subscription links are here: https://techleader.pro/a/617-Tech-Leader-Pro-podcast-2023-week-40,-social-media-is-a-brutal-mirror

This week my web search engine greppr came under a bot attack, in this episode I will discuss what happened and how I fixed it.


Notes:



Leaders, all of your problems are people problems. Mostly due to their poor communication skills.
This week a senior colleague got annoyed with me for not turning up to a meeting:


With a person I never heard of.
At a place and time I never received an invite for.

People regularly assume others have knowledge of something just because they do: then neglect to transfer that knowledge.
Somehow, we believe our mental model has magically impacted upon others, without ever actually communicating it to them. It's bizarre!
I discovered this phenomenon has a name: the curse of knowledge. Ref: https://en.m.wikipedia.org/wiki/Curse_of_knowledge
Wikipedia: "The curse of knowledge is a cognitive bias that occurs when an individual, who is communicating with others, fails to disregard information that is only available to themselves, assuming they all share a background and understanding."
I found a better definition on the website TheDecisionLab.com: "When we know something, it can be hard to imagine what it would be like not knowing that piece of information. In turn, this makes it difficult to share our knowledge, because we struggle to understand the other party’s state of mind." Ref: https://thedecisionlab.com/reference-guide/management/curse-of-knowledge
Leaders need to be master communicators, and cannot become that if they are not aware of their own cognitive bias.
What I am working on this week:

Apache Nutch is unstable, and eats up a lost of disc space.

Media I am enjoying this week:

Diaspora by Greg Egan.



Notes and subscription links are here: https://techleader.pro/a/616-Tech-Leader-Pro-podcast-2023-week-39,-the-curse-of-knowledge

This week my web search engine greppr came under a bot attack, in this episode I will discuss what happened and how I fixed it.


Notes:



I am running late this week due to exhaustion.
Last week, my web search engine greppr.org was attacked by a bot.
Initially I thought it was real traffic: I seen search queries coming in from multiple IPs, that on first impressions looked like real traffic.
However the volume was huge! At least, huge for my fledgling service that basically nobody is using.
On September 18th, I seen 30K additional search queries, and a further 25K on the 19th. I got excited!
On closer examination however, I could see patterns in the search queries: lots of weird searches for maid and cleaning services, from random IPs and user agent strings, all seconds apart from apparently different users.
Why did they do this? Perhaps they think they can inject this content into my site?
The fix: dynamic query string parameters that change daily, using an unpredictable pattern. Now, the bot gets 404 responses (it is still running).
Good bots should identify themselves via the user-agent header in HTTP requests: this is what the web crawler Greppr uses does, along with the bots from big search engines like Google and Bing.
Web security remains an arms race.
What I am working on this week:


Blog: "Choose your mentors wisely" - https://techleader.pro/a/614-Choose-your-mentors-wisely

Media I am enjoying this week:


Diaspora by Greg Egan.



Notes and subscription links are here: https://techleader.pro/a/615-Tech-Leader-Pro-podcast-2023-week-38,-analysis-of-a-bot-attack-on-greppr