@kevlin@mastodon.social
@kevlin@mastodon.social avatar

kevlin

@kevlin@mastodon.social

consultant • father • he/him • human (very) • husband • programmer • keynote speaker • technologist • trainer • writer

This profile is from a federated server and may be incomplete. Browse more on the original instance.

kevlin, to random
@kevlin@mastodon.social avatar

Just revisited a piece of code I wrote for a workshop nearly 10 years ago.

I recalled the code being 'clever' and 'elegant', but not necessarily very performant. Was delighted to discover that not only was all this still true, but that, in spite of the cleverness, it was actually clearly structured and comprehensible.

In fact, it was so clear and comprehensible that I now realise the cleverness was completely unwarranted and there's a simpler solution that's more comprehensible and efficient 🤣

kevlin, to random
@kevlin@mastodon.social avatar

As a human I want to be required to enter a default value in a field that shouldn't be present on an input form so that a developer doesn't have to change any code

kevlin, to random
@kevlin@mastodon.social avatar

One of the most annoying AI trends at the moment is the number of sites and apps trying to push AI assistants on to me.

The developers of these products already have more useful work they could be doing — as a user, I can tell 🙃 — and LLM integration is generally not solving a problem that people have with those products.

In amidst the already frustrating pop-ups and notifications, this new source of pop-ups and notifications is not particularly welcome.

trisha_gee, to Java
@trisha_gee@jvm.social avatar

If you're at Devoxx UK in a couple of weeks, come and see me and @kevlin and some Very Special Guest Stars tell you about 97 Things Every Programmer Should Know.

Tickets still available... for now: https://www.devoxx.co.uk/

Image showing head shots of Kevlin and Trisha and the title of their DevoxxUK conference talk, 97 Things Every Java Programmer Should Know

kevlin,
@kevlin@mastodon.social avatar

@ctietze @trisha_gee We might skip a couple... 😉

kevlin, to random
@kevlin@mastodon.social avatar

Judgment Day by Teedy Deigh

"when a dev uses LGTM it means they couldn’t be bothered to look through it
when an architect uses LGTM it means they haven’t a clue"

https://accu.org/journals/overload/32/180/deigh/

ctietze, to random
@ctietze@mastodon.social avatar

@kevlin Am watching your Technical Neglect talk at the moment. You mention "entropy", right after how "code rot" is not a good metaphor because the default of code is stasis.

WDYT: With your physics degree you know best: I recall that you can describe time (and the passage and irreversibility of it) via accumulation of entropy in systems.

So code that sits still & unchanged for 5 years doesn't have "time" happen to it.

Touch code → increase entropy; advance the actual code age → have it rot

kevlin,
@kevlin@mastodon.social avatar

@ctietze I sometimes relate the idea of advancing time with that notion of change, but the problem is that we also have the regular definition of 'time', hence why there is perhaps too much scope for misunderstanding.

kevlin, to random
@kevlin@mastodon.social avatar

Communicating is one of most significant yet also most challenging things that humans do.

So, in the spirit of communicating improvements, I want to highlight that clicking an option labelled "Keep me logged in", this has a simple interpretation in standard English: it means keep me logged in.

There's a variety of things it does not mean, including "Order me a coffee" and, perhaps most significantly, "Keep me logged in for a bit, but arbitrarily log me out at some point without notice".

kevlin,
@kevlin@mastodon.social avatar

If you don't mean what you say, and you already know that you don't mean it, don't say it.

If you're designing a website, part of UX is providing the user with information they can use to work the site, building a reasonable mental model of how the site works.

If your website includes arbitrary behaviours (e.g., arbitrary logout) that are not initiated by the user or by the business of the site, make it clear why and when those behaviours happen — and don't make promises you can't keep.

kevlin,
@kevlin@mastodon.social avatar

@arne_mertz Yes, deeply frustrating.

One of the other one's I notice is "Remember this device in future" if you logged in from somewhere new. That's fine and reasonable. But when it's the same damn machine. Every. Single. Time. Well, it gets old.

kevlin, to random
@kevlin@mastodon.social avatar

It's often observed that we spend more time reading code that writing it.

What many conclude from this is that we should aim to make that task easier by making code more readable; what we should conclude is that we should aim to create code that doesn't have to be read as often and that doesn't take as long to read.

The goal is write code that reduces overall reading time rather than thinking of the reading time as constant. Move that needle.

kevlin,
@kevlin@mastodon.social avatar

@ArneBab That's a great idea!

kevlin,
@kevlin@mastodon.social avatar

@ArneBab Looking forward to it

kevlin, to random
@kevlin@mastodon.social avatar

A reminder: in code, naming is a design activity; it is not merely labelling.

kevlin,
@kevlin@mastodon.social avatar

@xandor9 @underlap Oh, and then there's one of my all-time favourites: the class called Database.

Confused me as it had nothing to do with databases, so I asked the developer: "Oh, that's nothing to do with the database: it's the application controller. All the database stuff is in Database2." 🤦‍♂️

kevlin, to random
@kevlin@mastodon.social avatar

In today's workshop I'm introducing a new group exercise, one that seems to fulfil an oft unspoken need and question: compare and contrast microservices and modular monoliths...

... except that, given the cycles of technology/fashion and the reality of many so-called 'micro'-service implementations, I can't bring myself to call it 'microservices versus modular monoliths'...

... so the exercise is actually described as 'service-based versus component-based architectures'

kevlin,
@kevlin@mastodon.social avatar

The results of yesterday's service-based versus component-based architecture (a.k.a. microservices versus modular monoliths) were interesting.

Most of the proposed design benefits touted for services are the same as those that have been proposed in the past for components. (And, before that, for any modularity-based trend.) Perhaps, unsurprisingly for those who are familiar with software development history and human nature, many of these design benefits are proving difficult to realise.

kevlin,
@kevlin@mastodon.social avatar

Most of the drawbacks cited for components/modules/etc. are the reality of falling short of the hoped for benefits and are, therefore, also beginning to appear as perceived drawbacks of (micro)services.

Everyone said that managing, debugging, etc. services was harder (and, overall, doing services involved more infrastructure, complexity, dependencies and work).

Everyone mentioned scaling as a benefit of services; almost no one mentioned performance consequences and the network as issues.

kevlin,
@kevlin@mastodon.social avatar

The most notable mention of performance benefits of in-process modular approaches was the phrase "in-process RPC", which I pointed out just meant "procedure call".

We often get so used to jargon, we forget to decompile it when we throw it together with other jargon 🙃

kevlin,
@kevlin@mastodon.social avatar

This, in conjunction with a workshop I ran last month and questions I have asked at conferences and in other workshops, seems to confirm my suspicion that the majority of developers who currently develop microservices do not have a good working knowledge of the nature of distributed systems, how OS processes work or programming paradigms in general.

kevlin,
@kevlin@mastodon.social avatar

@adrianco Interestingly, this was not mentioned during the workshop session, but was mentioned outside it. In other words, it did not occupy their awareness and they were dragged into other factors.

kevlin, to random
@kevlin@mastodon.social avatar

Coined the term 'architecture theatre' yesterday during a workshop.

I was asked whether there was such a thing as 'too much architecture', and the participant then described a very hierarchical, bureaucratic, committee-driven approach that seemed to be innately opposed to the very idea of actually developing software. I said that if anything, as far as I was concerned, it was actually an example of 'not enough architecture', that it was 'pure architecture theatre'.

kevlin,
@kevlin@mastodon.social avatar

To quote the late Stefan Tilkov:

"Architecture is a property of a system, not a description of its intended design."

If your development process is focused on discussing and passing around descriptions of the thing you want to build, but you're not actually building, testing and learning from it, then rather than being focused on architecture, your process is studiously (and bureaucratically) avoiding it.

kevlin, to random
@kevlin@mastodon.social avatar

Delighted to discover that the photo used for the sculpture outside the Children's Hospital is one of my Instagram shots
https://secretbristol.com/public-art-bristol/

kevlin, to random
@kevlin@mastodon.social avatar

Ah, my website nemesis: poor validation and input processing.

Just entered my valid phone number to be told, in red, that my phone number was not valid. Was it the use of an international prefix? No. Was it that I used spaces in my phone number? Yes!

Forget NP completeness, AI fairness, etc., if we look at software as it is built, space removal has a claim to be one of the biggest challenges in modern software development 🙃

kevlin, to random
@kevlin@mastodon.social avatar

Yes, JavaScript has a lot of oddities, especially around what is or is not considered equal to another value, but I see a lot of posts/talks/etc. along the lines of "Here's a crazy JavaScript feature" that are actually not specific to JS at all and are well-specified and consistent across all languages that fully support IEEE 754 (and follow-on specs) for floating-point numbers.

kevlin,
@kevlin@mastodon.social avatar

@mlevison Yes, JS is a mess and I dislike it for a number of reasons, but I think it's important to be correct in one's attribution of its flaws — "OMG, it implements IEEE 754 as expected!" is not one of them 🙃

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • Leos
  • mdbf
  • magazineikmin
  • thenastyranch
  • Youngstown
  • osvaldo12
  • rosin
  • slotface
  • ngwrru68w68
  • InstantRegret
  • PowerRangers
  • kavyap
  • tsrsr
  • DreamBathrooms
  • tester
  • everett
  • hgfsjryuu7
  • khanakhh
  • GTA5RPClips
  • vwfavf
  • Durango
  • cubers
  • tacticalgear
  • ethstaker
  • cisconetworking
  • normalnudes
  • modclub
  • anitta
  • All magazines
    •