tinthedev

A bit cheap to hide all the criticism in the footnote, but otherwise - yeah. Fully agreed that the LLMs of today do help cruise past all the prior "roadblocks".

It's life-changing as much as any other good tool is/was. The printing press was massively beneficial, but the ideas needed to be there before they could be printed.

LLMs in their current stage are, (un)fortunately, just not reliable enough. They can get the 3/4 of the work done. Then you can refine the last part and get 1/2 of it done. Then the next iteration undoes a quarter of that... etc. etc.

It's a guessing game, and the guesses _are_ good. But as any capable engineer will tell you, the N% is easy, it's the (100-N)% that gets ya ( https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule ).

I like the article, and the message it's trying to get across.

This is one of those problems that a lot of organizations have, and that has a straightforward solution... but people don't apply!

I've found it one of easiest ways to boost productivity in any environment: eliminate decisions that don't produce artifacts.

If it wasn't written down, it might as well not have happened. Informal discussions and watercooler brainstorming is all fine and dandy, and I'm the first one who's not letting it go... but any practical work has to have outputs down - and in creating that hurdle, you're already more than halfways towards removing most inane arguments (what bike-shedding usually is).

The cost of participation needs to always be just a tad too high for knee-jerk reactions to be worth it :)

It's not? I opened the page and it worked just fine.

Oh, you've either got the CSS disabled, or you missed the implementation next to your scrollbar. Check the other comments.

Location: 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1 | Relocation only in most exceptional circumstances

Email: tinmarkoviccs (at) gmail.com

Tech/Resume/CV:

I'm a generalist and an opinionated software engineer with experience both in management and as an indepth technical designer, I am looking forward to work with you. If you need a larger team at your disposal, I can arrange that with my industry connections. I guarantee all my work will bring value, or I'm not charging for it. I'm not looking for "cog in the machine coder" type positions :)

Leave me your contact if you'd utilize my help with:

- Large web API implementations

- Automatic code quality checks and processes

- Software Engineer management coaching or mentoring

- Process and scoping help (how to leave development hell)

- Large data streaming and processing systems

... and plenty other things, really. I am certain we can figure out a way to solve your issues in the way that _brings joy_.

I've got 8+ years of senior experience (leading and managing projects and teams). I've recently written code in Go, TS (& React), and Python (deployment and architecture included) with traditional stacks (Postgre, Redis, Kafka, etc. etc) and I'm comfortable with all the modern web tech-stack. I've got some past experience with C#, PHP, and all kinds of scripting languages. I pick up languages quite quickly, so that shouldn't be a problem, and I've got a working knowledge of most programming paradigms.

Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)

SEEKING WORK | 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1

Email: tinmarkoviccs (at) gmail.com

I'm a generalist and an opinionated software engineer with experience both in management and as an indepth technical designer, I am looking forward to work with you. If you need a larger team at your disposal, I can arrange that with my industry connections. I guarantee all my work will bring value, or I'm not charging for it. I'm not looking for "cog in the machine coder" type positions :)

Leave me your contact if you'd utilize my help with:

- Large web API implementations

- Automatic code quality checks and processes

- Software Engineer management coaching or mentoring

- Process and scoping help (how to leave development hell)

- Large data streaming and processing systems

... and plenty other things, really. I am certain we can figure out a way to solve your issues in the way that _brings joy_.

I've got 8+ years of senior experience (leading and managing projects and teams). I've recently written code in Go, TS (& React), and Python (deployment and architecture included) with traditional stacks (Postgre, Redis, Kafka, etc. etc) and I'm comfortable with all the modern web tech-stack. I've got some past experience with C#, PHP, and all kinds of scripting languages. I pick up languages quite quickly, so that shouldn't be a problem, and I've got a working knowledge of most programming paradigms.

Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)

It looks wonderful, but the adoption will be a thoroughly uphill battle. Be it from browsers, be it from designs and implementations on the web.

I'll be first in line to try it out if it ever materializes, though!

Quite a fun read more often than not: https://dynomight.net/

Takes all kinds of lifestyle and tech topics and nerds out about them thoroughly. If you've ever wanted to see mundane things overanalyzed and backed with solid facts, I recommend.

I don't necessarily agree with all their views, but I've always enjoyed an article and it's rarely if ever confidently wrong.

I've coded some myself, and have used some... but it depends on where you draw the line.

I'd consider Python's f-string syntax a DSL of sorts.

YAML might be considered a simple DSL, if you don't consider it a language/format instead. It's a bit more than 2-3 pages, but it's not hundreds of pages. And a simplified version could be constructed with <10 pages.

Similar to YAML, but for Markdown. I'd call that a DSL too, and it's even simpler than YAML.

Then, something more tiered as: CSV, JSON, TOML, INI, AsciiDoc

Once you're in the short form, it's a bit blurry what's a format, what's a DSL, and what is a language.

PS. Sorry for the late answer, I missed the direct question for a bit.

I have a somewhat more wordy version of this blogpost as a conference talk I've done pre-COVID (and pre-kids). In my perception, this mostly boils down to reviewing and revising interfaces.

Code that's not well compartmentalized and is full of complex dependency chains and flawed abstractions is hard to work in, and more importantly to the topic at hand: extremely hard to refactor well.

Once the abstractions are shuffled to their own "corners" of the codebase, and you've got well defined modules/services/microservices/foobars... you'll find refactoring to be far less of an investment. It also becomes far less attractive, as a well abstracted module is easy to ignore and forget about.

Of course, it's always best to make these things right the first time. Whenever I kick off a greenfield project, my first code-style objective is to make things easy to delete/remove.

Addendum: I find the worst spaghetti code comes from very dynamically typed languages. All the "easy" coding makes skipping interfaces/abstractions effortless, thus nothing's "doing just one thing well" and it snowballs from there. On the flip-side, when done right, it's quite a joy to write delete-able code in Python, and it makes prototyping and defining boundaries a breeze.

SEEKING WORK | 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1

Email: tinmarkoviccs (at) gmail.com

I'm a generalist and an opinionated software engineer with experience both in management and as an indepth technical designer, I am looking forward to work with you. If you need a larger team at your disposal, I can arrange that with my industry connections. I guarantee all my work will bring value, or I'm not charging for it. I'm not looking for "cog in the machine coder" type positions :)

Leave me your contact if you'd utilize my help with:

- Large web API implementations

- Automatic code quality checks and processes

- Software Engineer management coaching or mentoring

- Process and scoping help (how to leave development hell)

- Large data streaming and processing systems

... and plenty other things, really. I am certain we can figure out a way to solve your issues in the way that _brings joy_.

I've got 8+ years of senior experience (leading and managing projects and teams). I've recently written code in Go, TS (& React), and Python (deployment and architecture included) with traditional stacks (Postgre, Redis, Kafka, etc. etc) and I'm comfortable with all the modern web tech-stack. I've got some past experience with C#, PHP, and all kinds of scripting languages. I pick up languages quite quickly, so that shouldn't be a problem, and I've got a working knowledge of most programming paradigms.

Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)

Location: 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1 | Relocation only in most exceptional circumstances

Email: tinmarkoviccs (at) gmail.com

Tech/Resume/CV:

I'm a generalist and an opinionated software engineer with experience both in management and as an indepth technical designer, I am looking forward to work with you. If you need a larger team at your disposal, I can arrange that with my industry connections. I guarantee all my work will bring value, or I'm not charging for it. I'm not looking for "cog in the machine coder" type positions :)

Leave me your contact if you'd utilize my help with:

- Large web API implementations

- Automatic code quality checks and processes

- Software Engineer management coaching or mentoring

- Process and scoping help (how to leave development hell)

- Large data streaming and processing systems

... and plenty other things, really. I am certain we can figure out a way to solve your issues in the way that _brings joy_.

I've got 8+ years of senior experience (leading and managing projects and teams). I've recently written code in Go, TS (& React), and Python (deployment and architecture included) with traditional stacks (Postgre, Redis, Kafka, etc. etc) and I'm comfortable with all the modern web tech-stack. I've got some past experience with C#, PHP, and all kinds of scripting languages. I pick up languages quite quickly, so that shouldn't be a problem, and I've got a working knowledge of most programming paradigms.

Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)

I agree with other posters that this is most likely a degree of title inflation, and a nice pay-bump. Likely worth the jump.

But I'd like to add a bit of nuance into it too. Be very careful about the real job description and expectations. Being in a VP position without actual institutional support to do your job can be burnout inducing (been there, done that). Make sure to enumerate your duties and your tools. You don't want to be caught managing a metric you can't budge.

Ah, and follow the money. If you can't manage your own branches' budget (at least to some extent), then you should refuse accepting responsibility at that level.

Wonders of middle management, eh?

It is quite expensive, isn't it? I've especially been upset that they've sunset the Pixel phone benefits with regards to Google Photos.

Used to be free (okay, that was too good to be true), then it used to be discounted... and now it's nothing, really.

My greatest pet peeve with them is the fact none of the applications allow you to filter videos out of the sync. So any automated tooling will quickly balloon your Google storage out of proportion with smartphone video... and give them a reason to pressure you for upgrading.

Enough ranting, though. On the topic, due to storage being so cheap...

I've personally set up SyncThing on Android and my home RaspPi (and my desktop, and a backup), so I'm having an auto-backup without real limits (3 USB sticks for redundancy, an hour of work) - that also doesn't train AI models with my face. It's worth the effort, IMHO. Plenty of guides online, and I've had literally zero issues with it so far.

This is the way.

The whole post, and both the Twitter messages sound like they refer to a very specific style of work.

These things "sound good but almost never work" when they're taken as an afterthought or committed to without due research/process/design.

Any architect worth their salt will avoid implementing hard solutions to these problems. These are mostly here to not solve crucial issues... but the article seems to be addressing a developer profile that adds APIs or asynchronous processing casually.

Sounds like a strawman, or just exceedingly pessimistic look at the industry.

This whole thread said exactly what I wanted to write. Feels bad to be so pre-empted.

DSLs that solve a specific problem with a page or two of documentation overhead are great.

Trying to reinvent paradigms or scope creep is where the pain comes in. Seems like the post author has been burned by that type of DSLs.

> almost entirely grassroots/bottom-up

Exactly.

I feel it's simply put:

Europe is just further on the left of the `labour - capital` divide. As a region with insane inherited capital (all the old money), this makes perfect sense.

A lot of US media laments the corporatism of the US, and in the next article lambaste EU regulations... not understanding the irony of their position.

The EU took its tradeoffs seriously, and committed to them. Whether it's a good position... I can't tell, really. Can't see the future. But it's a very visible and understood tradeoff:

Pressure the top 5% to provide for the bottom 95%. You can't get laid off and stress about food - because a failure includes paying all the laid off employees a severance. It's bad for starting a business... but is it bad for the people and the society at large? Call me a socialist, but I think people shouldn't have their livelihoods depend on the 2-week cycle of salary.

Should there be a framework for a more risk-hungry sector? Probably, something to mimic the US, but the avenues for abuse are exploited the moment loopholes open.

TLDR: Europe, and Europeans, do not _want_ the trillion dollar companies.

Nowhere did I say generated. The word I was using is generic.

I presume the artists have been paid a fair wage, but as the article describes, are focusing on derivatives.

The TLDR is that Spotify is flooding it's platform and padding playlists with cheap and generic music. They've went full "buffet" strategy, serving lots of fries so you stay away from the meats.

I think calling this payola, as the article insinuates,is wrong.

I was always more interested in finding artists than I was in finding songs. I've noticed Spotify recommendations being worse and worse, and I can happily say I've left the platform half a year ago. Didn't regret it a single bit.

The TLDR is that Spotify is flooding it's platform and padding playlists with cheap and generic music. They've went full "buffet" strategy, serving lots of fries so you stay away from the meats.

I think calling this payola, as the article insinuates,is wrong.

I was always more interested in finding artists than I was in finding songs. I've noticed Spotify recommendations being worse and worse, and I can happily say I've left the platform half a year ago. Didn't regret it a single bit.

Not to devalue the author, or their findings/learnings... but I could see this was a JavaScript/Typescript coder (very likely self-taught) learning about typing paradigms.

A lot of people, especially people from the same background, would benefit from branching out and learning some other programming languages/paradigms.

Some... statically typed and actually compiled languages. Maybe to take an entry course in CS.

It's very popular to hate on formal education, especially in software, but all these lessons would have been learned in the first semester or two.

This sounds quite interesting even from a non-AI/machine learning perspective (as a lot of posts are discussing that).

I'd say it's a quite important lesson in UI/UX design, and interfaces generally. As per the article, our brains are primed to:

> actively constructs event boundaries based on internal priorities rather than passively responding to environmental cues

Explains why ads effectivity is low, why a lot of users miss obvious cues, and why UI design is so hard. It's something a lot of professionals know intuitively and through anecdotal evidence.

It is quite interesting to see research dig deeper into it, and possibly research/develop better "levers" to pull human attention more efficiently - essentially make us remember things. Priming was long understood to help, and that's primarily from observation/empiricism. Deeper insights into how the brain itself handles this could be game changers.

Was quoting the library's docs.

I've actually used FastAPI's DI, which is a nice convenience. It didn't feel as a big selling point, again, due to this being Python. Wrapping up your own DI is near trivial, and barely feels like a pattern.

Thanks for pointing that out, I didn't even realize last night how weak of a selling point this is, even.

Feels like an in-between library that I'm not sure has a great fit in the current Python BE environment.

It's not as batteries-included as Django, primarily because Django's the incumbent and the ecosystem is vast.

It's not as modular and independent as Flask, which it's taking a lot of inspiration from.

It doesn't seem to bring enough to the table to be flat out better all-rounder than FastAPI.

I'm quite unsure where I'd use it instead of one of those 3.

From searching through the documentation and trying to find it out, the primary "secret sauce" seems to be Dependency Injection, quite a hard sell for a Python framework.

It is far less productive for complex anything, not just UIs.

The only way to do home-spun stuff in JS/TS is to narrow the use-cases and components down religiously. The moment you'll require more than 2-3 bits of the website to interconnect... take one long hard look at the future and avoid the headache of writing your own JS boilerplate.

I love eschewing JS frameworks as much as the next man, but I also love my free time. Too much to waste it debugging problems coming from hundreds of different user stories and approaches. React's mature enough, as are most of the big libraries commonly leveraged on it.

I've found it especially useful, in recent years, to eschew a lot of JS and go back to the "stone age" so to say, when developing non-public components.

I'd still not go without React (or something similar) to manage DOM in the user-land, but there's something blessed about using barely any to no JS at all in an admin/moderator UI, or in dev tooling. Don't have to consider any of the compatibility/update headaches outside of the user space.

That rant aside, I feel that the best approach to JS is a static one. Build your code and your artifacts, package them long-term... serve them when needed and you're done. It's somewhat retro, SPA style, but it works like a charm and doesn't require building all the time, nor babying all the dependencies and build steps.

> OpenAPI is too resty

I'm curious as to why would you think that?

There's a bit of boilerplate in there if you want to use it for a naive implementation, but I don't find it exceedingly resty.

From my POV, using protobuf as a schema declaration tool (as opposed to being a performance tool) is blind follower behaviour. Getting over all the hurdles doesn't seem worth it for the payoff, and it only becomes less valuable when compared to all the OpenAPI tooling you could be enabling instead.

This being for a web-based problem, where we're solving schema declaration.

Real software engineering is as far from "only writing code", as construction workers are from civil engineering.

> So, fellow software engineers, how do you future-proof your career in light of, the inevitable, LLM take over?

I feel that software engineering being taken over by LLM is a pipe dream. Some other, higher, form of AI? Inevitably. LLMs, as current models exists and expand? They're facing a fair few hurdles that they cannot easily bypass.

To name a few: requirement gathering, scoping, distinguishing between different toolsets, comparing solutions objectively, keeping up with changes in software/libraries... etc. etc.

Personally? I see LLMs tapering off in new developments over the following few years, and I see salesmen trying to get a lot of early adopters to hold the bag. They're overpromising, and the eventual under-delivery will hurt. Much like the AI winter did.

But I also see a new paradigm coming down the road, once we've got a stateful "intelligent" model that can learn and adapt faster, and can perceive time more innately... but that might take decades (or a few years, you never know with these things). I genuinely don't think it'll be a direct evolution of LLMs we're working on now. It'll be a pivot.

So, I future-proof my career simply: I keep up with the tools and learn how to work around them. When planning my teams, I don't intend to hire 5 juniors to grind code, but 2 who'll utilize LLMs to teach them more.

I ask more of my junior peers for their LLM queries before I go and explain things directly. I also teach them to prompt better. A lot of stuff we've had to explain manually in the past can now be prompted well, and stuff that can't - I explain.

I also spend A LOT of time teaching people to take EVERYTHING AI-generated with generous skepticism. Unless you're writing toys and tiny scripts, hallucinations _will_ waste your time. Often the juice won't be worth the squeeze.

More than a few times I've spent a tedious hour navigating 4o's or Claude's hallucinated confident failures, instead of a pleasant and productive 45 minutes writing the code myself... and from peer discussions, I'm not alone.

I'd gladly double up on your bet.

Frankly, I think it's ridiculous that anyone who has done any kind of real software work would predict this.

Layoffs? Probably. Layoffs of capable senior developers, due to AI replacing them? Inconceivable, with the currently visible/predictable technology.

Location: 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1 | Relocation only in most exceptional circumstances Email: tinmarkoviccs (at) gmail.com

Tech/Resume/CV:

I'm a generalist and an opinionated software engineer with experience both in management and as an indepth technical designer, I am looking forward to work with you. If you need a larger team at your disposal, I can arrange that with my industry connections. I'm not looking for "cog in the machine coder" type positions :)

Leave me your contact if you'd utilize my help with:

- Large web API implementations

- Automatic code quality checks and processes

- Software Engineer management coaching or mentoring

- Process and scoping help (how to leave development hell)

- Large data streaming and processing systems

... and plenty other things, really. I am certain we can figure out a way to solve your issues in the way that _brings joy_.

I've got 8+ years of senior experience (leading and managing projects and teams). I've recently written code in Go, TS (& React), and Python (deployment and architecture included) with traditional stacks (Postgre, Redis, Kafka, etc. etc) and I'm comfortable with all the modern web tech-stack. I've got some past experience with C#, PHP, and all kinds of scripting languages. I pick up languages quite quickly, so that shouldn't be a problem, and I've got a working knowledge of most programming paradigms.

Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)