DEV Community: Matthias Hryniszak

Why AI will never replace software developers

Matthias Hryniszak — Thu, 05 Mar 2026 01:05:36 +0000

So we are here. AIs like claude are threatening software developer's jobs. It is promised that "just coding" will be obsolete and solved with AI. It means that if you are a software developer you might want to be afraid if you will be able to pay your bills 2 months for now. After all, just like manual workers 50 years ago, your job is on the line. However.....

Neither all factories are fully automated and a ton of people still work in factories. What the fuck just happened? We've been promised/told that industrialization will kill so many jobs! So why there are still so many people still working in assembly lines? Shouldn't we have been at a stage where being an assembly worker is pointless with automation taking over?

Well, with all due respect for OpenAI CEO and all the backers of the AI movement, I have seen it in 1st person how incredibly immature, dull and stupid AI can be.

To bottom it all up: if you are a software developer and have like 5+ years of XP under your belt you are at least 20 years safe to keep your job - if history has anything to say about it.

If you've got 20+ years of XP as a software developer you will probably be paid more in the coming years than you can spend (if you are clever about it).

And if you are, like me, one of the dinosaurs of software development, sky is the limit for what you can become in the coming years. The Nirvana just arrived. And as much as OpenIA, NVidia and others would like to see us being obsolete we are in a better shape than ever before.

Keep on learning and you'll be fine.

Vite config reuse

Matthias Hryniszak — Thu, 25 Jul 2024 13:10:43 +0000

Have you ever wondered how big a Vite configuration file can get? What if you have a project with tens of workspaces? If any of the issues sound familiar - read on! There's something cool coming your way!

Writing reusable Vite configurations

As luck would have it, there is a function exported right from the vite package called mergeConfig(). It takes 2 arguments, essentially 2 fragments of Vite configuration and merges them together.

Based on this we can create a base configuration to use for all our projects. For example, I like all my vite-based projects to have eslint enabled. Here's how you would define it:

/**
 * @param {import('vite').UserConfig} overrides
 */
export function defineBaseConfig(overrides = {}) {
  const config = {
    plugins: [
      eslint({
        lintOnStart: false,
      }),
    ],
  }

  return mergeConfig(config, overrides)
}

Now, instead of importing defineConfig from vite you would import this function and define all your other configuration options (besides the eslint plugin) as usual.

All things being equal, here is how you could combine multiple functions to essentially build building blocks of configuration:

/**
 * @param {import('vite').UserConfig} overrides
 */
export function defineTestConfig(overrides) {
  const config = {
    test: {
      setupFiles: [
        './vitest.setup.js',
      ],
      coverage: {
        enabled: true,
        reporter: ['text', 'lcov'],
      },
    },
  }

  return mergeConfig(config, overrides)
}

/**
 * @param {import('vite').UserConfig} overrides
 */
export function defineDefaultConfig(overrides = {}) {
  return defineBaseConfig(defineTestConfig(overrides))
}

Now, whenever you need a Vite-based project with eslint and vitest all you need to do is to use the defineDefaultConifg(), create the vitest.setup.js in your main project and your configuration is done.

Ready-made configurations for you to use

I'm a lazy man. Extremely lazy. I hate repeating myself. That's why I created those 4 packages that I can later on use in my projects:

@padcom/vite-config-default - for use in other configurations

@padcom/vite-config-lib - for use in TypeScript libraries

@padcom/vite-config-vue - for use in Vue.js applications

@padcom/vite-config-vue-lib - for use in Vue.js libraries written in TypeScript

They are written in plain JavaScript. You can easily navigate to their implementation in vscode to see what is being configured and how. The main thing that you might find odd is those configurations make use of the contents of your package.json for a lot of things. That's why the first parameter is the package.json imported like so:

import pkg from './package.json' with { type: 'json }

And then if you need a Vue.js library then simply:

import { defineVueLibConfig } from '@padcom/vite-config-vue-lib'
import pkg from './package.json' with { type: 'json' }

export default defineVueLibConfig(pkg)

That's all! Isn't it nice?

So is that really all I need to do?

For Vite - yes. For your library - there is a little bit more to it, and it not because of vite, but because you're doing a library that exports things.

First of all, you need a proper exports definition for your library. The final build will reside in the dist folder and will contain the following files, assuming your project's name property is set to shiny-components:

{
  "name": "shiny-components",
  "type": "module",
  "files": ["dist", "README.md"],
  "exports": {
    ".": {
      "require": "./dist/shiny-components.umd.cjs",
      "import": "./dist/shiny-components.js",
      "types": "./dist/types.d.ts"
    },
    "./dist/style.css": "./dist/style.css"
  },
  "dependencies": {
    "vue": "^3"
  },
  "devDependencies": {
    "@padcom/vite-config-vue-lib": "^0.2.0",
    "typescript": "5.1.6",
    "vite": "^5.2.10",
    "vitest": "^1.5.2"
  }
}

Please note, that each library you want your library to import but not bundle needs to be declared in dependencies. Likewise, if you want your library to bundle another library then put it into devDependencies. That is the reason why the pkg needs to be passed on to defineVueLibConfig()

And that is really all there is to it! Have fun creating your own configurations or using mine. Let me know how it made your projects more maintainable :)

Have a nice day!

mrdr is born (from hell!)

Matthias Hryniszak — Wed, 22 Nov 2023 22:01:59 +0000

I've been doing node and frontend for years now. More than anything, it bugs me that some things that should be simple are so darn difficult. For example, setting up projects...

The bad

Imagine you have a monorepo that contains a common library and two projects that use it. It makes perfect sense that you'd like them to be in dev mode at the same time, so that during development you can treat the whole thing as a whole. It's just easier to think about it this way...

The ugly

There is a catch, though. You can't start the dev server for your apps until the common library is done. So what do you do? you start the build watch in one console and once that has finished you start the next console and run the build for your app1 and a third console for the second app.

To say that it is tedious is like not saying at all.

And then there's the final build...

Of course, you can employ tools like turbo for the final build (doesn't work for dev mode as you can't dependOn persistent tasks!) and it works quite well, but then you ask yourself, why is that tool so stupid? If I already have a build task in all my projects, why do I have to again express that build depends on build? That's ridiculous, to say the least.

mrdr to the rescue!

mrdr (pronounced appropriately /mordor/) is exactly what you would expect a runner like that to be. It assumes that your build task is called build and that your dev task is, well, called dev.

When you have things laid out like that, all you need to do to start your dev environment is:

npx mrdr

and off you go. The build -w will keep on running but once all the exports are there, it will continue on with projects that depend on them.

It really is that simple!

If you want to build your project in order you run

npx mrdr build

and life is good again. No more wait-on, no more turbo.json, no more hassle.

Credits

Although I wrote mordor myself there is a person that deserves recognition. Aleksej Dix pushed me to do it. I was thinking of it for a long time, hoping that some other person will do it instead, but he finally bugged me so much I've had to do it. Thank you, Aleksej, for being such a good friend!

Processing for the masses - p5js on steroids

Matthias Hryniszak — Thu, 22 Jun 2023 22:46:14 +0000

Very recently I have discovered The Coding Train YouTube channel. At first, it was kinda weird for a moment, but after two or three videos I was completely sold! I wanted that power of Processing for me! And I wanted it NOW!

As usual in those nice, academic cases, tooling support is, let's just say, somewhat lacky. There is a playground you can use to, well,... play around, but any sort of serious work requires a proper setup with TypeScript, ESLint, proper IDE support for in-place documentation and code completion. I don't think there's a single person on the planet that knows all there is to Processing, is there?

And so, now, ladies and gents... (drummroll) Badum-tss! Here it is! The all-mighty all-in-one with a cherry on top template you can use NOW!

npm create -y from-github padcom/p5 hello-world

You then need to install packages (as with any npm-enabled project):

cd hello-world
npm install

and you're ready to start coding (assuming you do have vscode installed):

code .
npm start

In a matter of seconds, you're coding in a TS-enabled, ESlint-backed, full-blown development environment with features you never even dreamed about, but might also be quite familiar to you if you are a frontend developer. In essence, everything that Vite.js supports is supported.

Ok, buuuuut... HOW MANY SECONDS?!

padcom@padcom:~/learning/p5$ rm -rf ~/.npm hello-world

At this stage, my local installation is totally fresh, nothing's cached. So we go with the worst-case scenario:

padcom@padcom:~/learning/p5$ time npm create -y from-github padcom/p5 hello-world
create-from-github version 0.0.4 by Matthias Hryniszak <padcom@gmail.com> 

cloning https://github.com/padcom/p5 ...
cloning https://github.com/padcom/p5-template ...
cleaning up hello-world ...
configuring hello-world ...
done.

real    0m5,003s
user    0m0,875s
sys 0m0,116s
padcom@padcom:~/learning/p5$ time npm i --prefix hello-world

added 165 packages, and audited 166 packages in 14s

36 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

real    0m14,205s
user    0m2,648s
sys 0m0,476s
padcom@padcom:~/learning/p5$

That's about 20 seconds. I call that acceptable, especially that it will save me a lot of time later.

But ok, you don't do that to have just one project, do you? You'd want to use that opportunity and start 10, 20 or a 100 small projects, some will live forever and ever, some will die 10 seconds after they were created.

Here's how fast it is to create the next project:

padcom@padcom:~/learning/p5$ rm -rf hello-world
padcom@padcom:~/learning/p5$ time npm create -y from-github@latest padcom/p5 hello-world
create-from-github version 0.0.4 by Matthias Hryniszak <padcom@gmail.com> 

cloning https://github.com/padcom/p5 ...
cloning https://github.com/padcom/p5-template ...
cleaning up hello-world ...
configuring hello-world ...
done.

real    0m1,209s
user    0m0,603s
sys 0m0,054s
padcom@padcom:~/learning/p5$ time npm i --prefix hello-world

added 165 packages, and audited 166 packages in 1s

36 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

real    0m1,218s
user    0m1,529s
sys 0m0,307s
padcom@padcom:~/learning/p5$

Less than 3s to have a new project ready to work. Sounds like a winner to me ;)

And the cherry on top I promised?

How about in-editor debugging with step-by-step code execution?

We've got it all wrong!

Matthias Hryniszak — Tue, 02 May 2023 01:37:27 +0000

How many times have you heard: "We're only going to get the architect for the first X time of the project. Then he'll be 'on-demand'"? How many times (besides total fuckups, of course) did hi actually show to meetings?

Why is that the case?

I think the main reason for this state of things is that there is somehow a notion that architecture is something that needs to be set in stone once, and then everything is built on top of it. There is somehow this connection to buildings and that once an architect has designed the building it stays throughout the build process.

I hate to break it to you, but oh man is that metaphor false to the deepest levels of hell!

Comparison to building a house

So let's say there are 4 stages to building a house:

getting a land
designing a house
building it
using it

If you think about it, then building software is pretty-much the same - only the names are different:

securing founds
building it
deploying it
profiting (hopefully!)

Now, there is a difference in the two middle stages.

Designing a house

Traditionally, in the real estate business, changing a design from a block to a wing-based system is not a thing that's done very frequently. After all, once the general shape of it is set, everything else it built "on top of it".

It's even less possible once the construction phase starts, and it turns out the entire groundwork needs to be undone, including the first and second floors of that 20 stories building. That would be madness, right?

What if I told you that while you're living in your freshly built house, someone would scale it up and down depending on how many people are currently present? Or even depending on which room they're occupying. That's a mind-fuck, isn't it?

Designing a software

Well, what if it wouldn't be that insane to think that you do have the possibility to redesign the general plan of the building, even change the number of floors dynamically and then to test, like "for real", if that meets the client's need?

Guess what! That is exactly how software is done!!!

So architects think they design something, and then it's like the basement and bricks - all set in stone. But in point of fact, it is very much not. It's subject to change just like every other part of the system, be it a single line in a back-water services or the key optimization of the company's most treasured secret AI whatever.

And if it isn't...

Architecture is just code

Countless times, I'm asked to draw pretty pictures of the architecture of a system I work on. I have no idea how is that going to help anyone understand what I need them to do if they don't even understand how a simple for loop works, but hey - the customer wants, the customer gets.

The problem with that is, that the non-tech guys trying to understand the grand design do think about it as the architecture plan of a house. It is not. It is not a house we're building here. Just please, get over it, m'key?

Now that we have that out of the way, I need to make sure we are on the same page here:

Architecture is the result of all coding activities, both heavenly-inspired and hellishly-guided. It doesn't matter who told you otherwise. No amount of pretty pictures will ever give you an accurate insight into an architecture of a system than the code itself. That is where The Architecture is. And it needs to change!

The goal of an architecture

It is my strong belief that coding is not only an art. It is a mixture of both craftsmanship and art.

As such, software development takes skills, out-of-the-box thinking, but also professionalism and modesty. I don't care if you're the CTO of some company or a junior that just joined. If you're wrong, and you can be proven wrong, then you're wrong. It will surface sooner rather than later.

That adheres most of all to architects. From my experience, those are guys that join a project in the beginning for a few days, set up some scaffolded horse manure, shout how "XYZ has taken over the world of software development and it sexy it will all be". Then they unload a whole pile of crap onto a team that has no idea what the actual fuck is going on. Weeks from then, the team has finally gotten rid of the bullshit introduced by the highly paid individual, but they're so bored with the project that even the newest toys don't motivate them to work on the project anymore. In other cases, the architect was so messed up the project, even though perfectly doable in the allotted time, will either stretch or be abandoned all together, causing investors to lose money.

It's sad, but true. Just look at the rate people change jobs in IT. It's madness!!!

Architecture is in the code

Ok, you might say that we don't have architecture in how the services are deployed or how they run on the server. First of all, that's no longer true if you use something like docker with docker-compose or k8s, and with that, you can again start thinking in a bigger picture - the architecture level.

But does that mean you can't add/remove services? Well... you can! And you can't - if you want your system to remain stable. That's a common problem in software development called "dependencies" and has been solved like in a million different ways. Why is that still a problem with the architecture?

I think it is a mental problem, not a technical one.

Properties of a system's architecture

We can reason about code. We can spot code-smells, review the changes being introduced, and all that corpo-nonsense we do to make sure that even if this is the one day in your life you were not thinking straight, there will be someone watching your back. That's how professionals do things.

But that means that if you think about architecture as part of the code, then for example, introducing a dependency on another system shouldn't be the architect's decision. It should be the architect's initiative before anyone even started asking about it.

Let's get technical

So, I hear you say: "if architecture is in the code, does it mean that it can be refactored?". And the answer is obviously a big, fat "Yes!". The only difference is that, on that level, you don't deal with concrete classes and direct inter-object relations. You deal with subsystems, concepts, lines of inheritance and inter/extra-system communication rather than discrete implementations of some subsystem's internal caching whatever.

That means that there does not exist a generic programming language that would be "for the architects". There are concepts, architectural guidelines that indeed can and always are implemented in a general-purpose language, but it's often so convoluted that the meaning of it is completely lost in the mud.

That is a sign of bad architecture.

Refactorings

Here are some examples of refactorings that I would put in the "architectural changes":

extracting a separately hosted service from another application
moving a responsibility from one hosted service to another
removing dependency on a service
sunsetting services
introducing a range of services with a common theme
refactoring services to line-up with a common theme of other services
maintaining service lifespan

Now imagine there's a developer, that has a library that has named exports and proper in-line docs, and he'll just interact with those classes. They will indeed do the architectural things, like spawning new services and the like.

Now imagine that developer being is asked to introduce a new type of service the company just produced/bought. It has a foreign interface, so you use the design patterns at your disposal to connect it to the rest of the system.

It's still coding. It always have been. It always will be.
No matter what everyone else will tell you.

It's just the libraries are different and sometimes things are better expressed using a DSL or as a graph of objects (say a yaml file) than code in some "proper" programming language.

But it is still code. It needs to be maintained. It needs to be kept on-par with what the rest of the project needs. And if something's is wrong with it, it needs an architect to fix it. And believe me, once you realize that all that is just code, you won't believe how many refactorings your architecture will need and how much more effective your teams will be!

Closing thoughts

Having said all that above, I think teams leveraging a coding, in-team architect stand a much better chance of success. Not only will the rapid response force be there all the time when you need it, but your other guys will have someone to learn from, to guide them. If you only allow your "best guys" to dump a truck load of horse manure on the devs and leave, don't expect them to eat that shit and be happy about it.

Happy coding!

Inspired by https://www.youtube.com/watch?v=9A9ZxIrc9CE

Working with streams in Node.js

Matthias Hryniszak — Sun, 09 Apr 2023 11:52:02 +0000

When working with streams one of the coolest things ever is using async generators to do piped processing. Let's start with a simple example that generates numbers from 1 to 5:

const numbers = async function* () {
  for (let i = 0; i < 5; i++) yield i.toString()
}

This generator yields 5 numbers, 0 through 4, as strings. Let's pipe them through to see them on the screen:

Readable.from(numbers()).pipe(process.stdout)

Boom! Just like that, we're printing the content of the stream to standard output. Let's see how we can do the printing using console.log():

const logger = async function* (
  source: AsyncGenerator<string>
) {
  for await (const number of source) {
    console.log(number)
  }
}

Readable.from(numbers())
  .pipe(Duplex.from(logger))
  .resume()

The call to Readable.resume() at the end makes the stream pull all the values and process them.

What's interesting here is that we're using a Duplex stream created from an async generator. Since it is a Duplex stream (so Readable and Writeable) we can still process the data further. For example, we can augment the numbers with some description:

const augmenter = async function* (source: AsyncGenerator<string>) {
  for await (const number of source) {
    yield `This is number ${number}`
  }
}

Readable.from(numbers())
  .pipe(Duplex.from(augmenter))
  .pipe(Duplex.from(logger))
  .resume()

Please note that the source argument to all the generators have a generic type, that will determine the type of element we are iterating over. In our case, the generic type is string so the number variable is of type string.

I think that's totally cool - how about you?

Happy coding!

Pipes! Pipes everywhere!

Matthias Hryniszak — Tue, 28 Mar 2023 08:40:18 +0000

I love small bits that do great things. This time it's about adding the pipe() method to any object, e.g.

const items = [ { price: 1 }, { price: 2 } ]
const sumPrice = (acc, item) => acc + item.price
const sum = pipeable(items)
  .pipe(items => items.reduce(sumPrice, 0))
  .pipe(sum => sum++)

And on and on, you can pipe the result of one callback to another, with the first callback receiving the pipeable value.

Now, how do we type this so that it makes sense in TypeScript?

export type Pipeable<I> = {
  pipe<O>(transform: (input: I) => O): O & Pipeable<O>
}

Having the type definition of the Pipeable type let's try to implement it:

function pipeable<I>(input: I) {
  const result = clone(input)
  if ((result as any).pipe) {
    throw new Error('Error: object is already pipeable')
  }

  const pipeableResult = result as Pipeable<I>
  pipeableResult.pipe = <O>(transform: (input: I) => O) => pipeable<O>(transform(result))

  return result as I & Pipeable<I>
}

Depending on your needs, clone can either have a trivial implementation like this one:

function clone<T>(input: T): T {
  return JSON.parse(JSON.stringify(input))
}

or, you could go full on with packages such as clone-deep.

nano-pinia

Matthias Hryniszak — Sun, 12 Mar 2023 02:21:19 +0000

One of the best qualities of Pinia is that it is actually a way to properly implement the singleton pattern. You define it as a function that always returns the same value.

I thought, since Vue already exposes the reactivity system as a separate package, can I implement singletons just like Pinia does - just without Pinia? What if I chose to only use the composition API?

function defineSingleton(cb) {
  const state = cb()
  return () => state
}

That's it - nano-pinia in 4 lines or less :).

You use it just like you would use Pinia:

const useStore = defineSingleton(() => {
  const x = ref(1)
  const y = ref(2)
  const sum = computed(() => x.value + y.value)

  function incY() {
    y.value++
  }

  return { x, incY, sum }
})

// use the store instance directly
const s1 = useStore()
s1.x.value = 5
// or destructure the content
const { incY, sum } = useStore()
incY()

// it doesn't matter - it's a singleton
console.log(sum.value) // outputs: 8

I think it's cool that you can do that with so little effort :) And it's a nice example of how to use closures - but who cares, right?

What's so difficult about being a software developer in 2023?

Matthias Hryniszak — Tue, 31 Jan 2023 20:08:18 +0000

A lot of interesting events happened lately. Big companies letting people go, even if they were with the company for a long time. Shocking as it is, it's been a long time coming. Software development is hard, really hard. It's not a hammer and chisel that you'd need a year to master, 5 years to become a master craftsman and a lifetime to become an artist. Programming isn't a form of art. It's more a craft than anything else. It takes time, effort and a tiny grain of talent - like anything else.

But how complex is it, actually?

Complexity for the rest of us

I find that generally speaking, putting things into perspective helps people understand the meaning of something. That tends to sink in better. Most adults use some form of mechanical transportation like a bike, scooter, car or plane. Let's use that to our advantage.

Learning curve

Learning to make the computer do what we need it to do on the most basic level takes about the same as learning to drive a motorbike. I don't mean passing the driver's license exam, but just basic handling, maybe switching gears and turning without visiting the hospital. It's not impossible, but takes time and effort. Funny enough, young people seem more courageous. It is just easier to learn to drive a motorbike on your friend's rusty old-timer when you're 15. There's a lot of fun in the process, which helps a lot to get it right. Even if you trip and fall, the worst thing that can happen in such a controlled environment will be a few broken dishes.

It feels like you could conquer the world! Then you learn that besides just going straight and around the block, there are rules you need to follow to limit the chance of messing things up. You learn to pass the exam and if you've spent enough time learning you will succeed. Once you're allowed to take off on your own for the first time, all of a sudden, the motorbike has like 200 HP and can do wheelie for miles on end. That, however brief, fascination either ends with someone dead or scarred enough to stop being irresponsible. That's when you either learn or fail. Generally speaking, youth goes by its own set of rules that rarely carry on into adulthood.

Once you get a bit older, a car is more what you need. So, you learn and practice passing the driver's license. This, as all drivers will tell you, doesn't make you a racing driver - far from it. Suddenly, you go slower than the motorbike, but you also carry more passengers. The responsibility rises and so does your insurance cost. In many countries, there are additional rules for drivers with less than a year of experience that include speed limits, number of passengers. In extreme cases, for the first 6 months, you might be required to have a seasoned driver to always be present in the car. You know, just to keep you safe in those rare cases you'll panic, close your eyes and let it happen. That should eliminate the urge to go all pedal to the metal, but we've all been there, and we've all done it, didn't we? Just this one time to see if it will do 160, empty road, no one in sight, YOLO!

Congratulations! You're a junior!

Then there's a period of I know I'm in control, where you don't really think about everything you do. Instead, you let your muscle memory take over. You operate on a whole new level. You're turning the car, shifting gears in the process and accelerating - all at the same time without even thinking about it. It's all so natural, cool and easy. Switching from one car to another does take a bit of effort, but it is generally possible to even switch between different transmission types (and then to realize what an idiot you were sticking to the stick) and it's not that big of a deal.

Congratulations! You're a software developer!

I'd say that most people will end their passion for driving there. There are more important things in life than realizing your youth passion for becoming the next Michael Schumacher. Not only is racing kind of dangerous, but it's also costly. And it requires significant effort to be any good at it.

But then there are situations in life where you need to go to the UK, rent a car and go to The City. Well, my friend, that's a whole different story. Nothing works the same, muscle memory works against every instinct you have. It's a horror! And then they come right at you! Crazy people those Brits are! (I love you guys, you know that, right? <3). But if you do it slowly, step by step, your muscles will learn. It takes a while to get the basics off the ground. For example, the driver's seat is on the other side of the car, go figure! I dare you to try to not make that mistake the first time you'll be getting in. It's a bit funny, enlightening, stressful, but at the same time interesting and rewarding once you give it some time.

Congratulations! You just discovered the other side! (backend/frontend)

You are still not Robert Kubica, you're a responsible citizen after all, but you can easily drive anywhere in the world. Nothing can stop you, and it feels fucking outstanding! That does mean something. It's been a long road so far, but the reward is worth the effort.

In some rare cases, you might want to make a living driving a truck. That's a cool idea, definitely not for everyone, but it pays the bills. Training is a bitch, costs a fortune and the exam is really hard. After you pass it, you don't have enough practice, but you know the rules, and you can consciously apply them to your daily routine. It's still stressful to park at the ramp, but with each time, you get more and more used to the procedures, red tape and people around you. Then, one day, you feel it's almost effortless. You make more and more money and life gets easier.

Congratulations! You just became a senior developer!

You probably work on your own, using some kind of distributed system to find people you can carry transport for. At this point, it isn't so much about the driving, but more about handling the business. You just became a businessman, so all of a sudden your taxes look differently, you've got options you didn't have before.

For example, you now could lease more cars, hire more drivers and expand the business. It really requires great effort, and very seldom people get to run a million-dollar enterprise. But if you do, you're the architect of your own success. You can effectively communicate with all kinds of people, you're responsible enough not to do crazy moves that will cost you, or your company, its existence. You need to coordinate a ton of things, and you wouldn't believe how crazy some situations can get! If you and your business survive for a few years and keeps growing, you are among the lucky ones.

All glory be to you!

Congratulations! You just became an architect!

You don't drive anymore, and if then very seldom, constantly on the phone, keeping the business going.

To keep things simple, let's follow that story to the end where your company grew beyond your wildest dreams, you now are the boss of all bosses and don't really work anymore. You're there, but the business is so well-designed it rarely, if ever, requires your immediate intervention. You're more responsible for the overall direction where the company should go. If it should grow or shrink, whether the fleet should go all electric or not. Those are the important or live changing decisions that you are uniquely suited to make.

Congratulations! You just became the chief architect!

As you can see, up to a given level there are rules that when followed keep you on the rails. Some of those rules you will break, that's inevitable. With time, you'll learn the consequences of your choices. It's not something you can learn from someone. I mean, of course that'd be absolutely wonderful if we could transplant clones of individual synapses from someone who's been there and done it, but that's not how the world works. We learn by failing.

At one point, you might want to give someone advice that'll save them a ton of time and produce exceptional results, but it's rarely the case the person will actually follow it. They are in a different place and this advice might plain and simple be no good for them. With time, you learn how to sell your ideas, maybe you could become active with the local community, give a bit back to the world. After all, it feels great to help others! It feels like you can cure world hunger, AIDS and syphilis - all before lunch, with plenty of time for an afternoon golf session with the prime minister. Now, that you have a lot more time on your hands, it seems to be an adequate option for your personal growth.

Congratulations! You just became a mentor!

That's the end of the story. The last thing is to realize where the industry is at, given the analogy.

half of the developers have less than five years of any kind of experience, that includes the basics, maybe up to the trial period of 6 months of driving under supervision
about 85% of developers are incapable of creative thinking
about 75% of developers are incapable of constructive problem-solving
nobody learns from technical literature anymore because there is no time for it. The industry learns from documentation that is half-baked and rushed to production, but has ready to copy and paste examples that you can tailor to your needs. Plus, the books are difficult to understand if you lack the basics
the industry drastically overestimates candidates during interviews. It is not uncommon to hire someone right off the school as a senior, just because
it pays a lot, everyone wants to make easy money, and...
the demand for new software is ridiculous!
on top of all this, every damn car handles completely differently and is obsolete after you've learned to get it off the ground. Some drive forward, some drive forward and backwards, and some fly sideways and upside down. Literally. And there is a new model every 5 minutes, that you need to be able to handle or else you won't find a job.

Closing thoughts

There are and always will be people who at a young age, through their brilliant minds and hard work, achieve fantastic results. But that is not everybody and is indeed an exception signifying the rule. You can always learn more, you can always get better, but that comes at a cost of time, blood and sweat and tears, and not because you just want it to happen.

Type-safe object builder in TS

Matthias Hryniszak — Mon, 24 Oct 2022 22:31:05 +0000

Long story short - object builder pattern in TypeScript :)

type Builder<Source extends object, Target> = {
  [Prop in keyof Required<Source>]: (value: Source[Prop]) => Builder<Source, Target>
} & {
  build(): Target
}

This type defines an object that will have methods of the same name as the Source object plus the build() method.

Here's an implementation thereof using Proxy:

function clone<S, T>(source: S): T {
  return JSON.parse(JSON.stringify(source))
}

function builder<
  Source extends object,
  Target
>(
  source: Source,
  convert: (source: Source) => Target = clone
): Builder<Source, Target> {

  const proxy = new Proxy<Builder<Source, Target>>(
    source as any, {
    get(target, prop: string, receiver) {
      if (prop === 'build') return build
      else return (value: any) => setter(
        prop as keyof Source, value
      )
    }
  });

  function build(): Target {
    return convert(source)
  }

  function setter(
    prop: keyof Source,
    value: any
  ): Builder<Source, Target> {
    source[prop] = value
    return proxy
  }

  return proxy
}

And here's how you could use it:

const b = builder(
  {
    x: 1,
    y: 'Hello'
  },
  source => ({
    o1: { a: source.y, b: source.x },
    o2: { p1: source.x, p2: source.y },
  })
)

console.log(b.x(3).y('2').build())

Each call to the builder methods is type-safe so it should be easy to work with it :)

Happy coding!

Software Development Myths

Matthias Hryniszak — Tue, 18 Oct 2022 13:28:11 +0000

Have you, as a software developer, ever been told you have to know the business? That you have to dive deep, and you have to understand the client's needs?

Well, I in my 30 years of experience, have obviously heard that time and time again. Pretty much every single time I change projects or jobs, I hear the same thing from both product people as well as from devs that have already been working on the product for years. And I flat out disagree with it. Here's why.

Required skills

So when you look for a new position you're seldom, if ever, asked about your business knowledge. You're harassed over and over again about frameworks, SOLID, DRY, TDD and what not but the questions about the business area are always left as "ok, so you seem worthy and here's what we actually do". Nobody is actually asking if you know how the planes work or how the financial sector works, because the assumption is that you either "should just know it" or "you'll learn".

How about other professions?

That assumption alone is just crazy. You wouldn't expect a dentist to know how to treat heart disease, let alone how to sell houses, but you'd still expect the teeth to be fixed if it is broken. That is what you pay for. It'd be actually hilarious to come to the doctor and tell him you have problems at work and expect that doctor to tell you anything that would help you. It's not what doctors do. They heal people's bodies. Of course, there are doctors that heal the brains too, but anyone who has seen a shrink knows they don't know shit about the job you do. Their preoccupation is your brain, not your work. Even if the problem is connected, the shrink won't help you solve that problem, but rather will help you help yourself.

So what about devs?

Why then developers, that deal with code, not with cars, planes, houses, and whatever else, are supposed to be experts at this or that business domain? The answer is, just like with doctors, they are not. Developers will, naturally, assimilate a portion of how the business works while working on a project, but that's accidental knowledge. To put it bluntly: if you want a dev that knows everything about the business, you need to train a non-developer that knows it to become a developer. There is no other way around it.

Sure, sometimes you'll find a guy that likes coding and has a kick for, let's say, aviation. It's a sexy topic on its own, so it's not that unheard of to meet people interested in both. And that's true for every business out there. But it is, and has rarely been, a point of interest for recruiters. I have never heard of a candidate that was rejected because of lack of knowledge about some business area...

So what's a dev to do?

The myth about developers having to learn about the business is just rude and impolite towards the devs because it treats the skills that we have as second-grade. Let me remind you that in 99% of the interview questions you won't find anything about the business itself. It's all technical.

The way to go is to have realistic expectations. If you need a person that knows, for example, what a hospital patient needs then you should ask someone who is directly involved with patients - not a guy who 6 months ago was writing a game about slashing zombies. The dev will know how to present the scanned image in a 1000 different ways, but in reality all of them are equally good. It is in the hands of whoever knows the business to figure it out and it is in the very capable hands of the developer to make sure whoever comes next will understand what the fuck you meant when writing code that translates business requirements.

Punchline

For you, as a developer, it makes all the sense in the world to learn about programming. It's a tool you get paid to use and the better you are at it the more you will be paid. It is that simple.

If, by any chance, you get interested in the area you work with - even better. Expecting that every developer will do that is just hilariously misguided and will render the codebase you work on useless due to lack of technical skills. I've seen it done a number of times specifically because the devs working on it were just very poor at actually programming.

As for the rest of us... Just keep doing what you do best. Someday the world will understand that a doctor is not a police officer and a developer is not a business expert.

Using an F405 flight controller with INav and Arducopter - Serial ports

Matthias Hryniszak — Thu, 24 Feb 2022 03:14:16 +0000

It is a bit confusing what to put where when connecting an F405 (like Matek F405-STD). Here's my proposal:

USART3 - CRSF
UART4 - MSP
USART1 - GPS
UART2 - OpFlow
UART5 - TBS SmartAudio

Hope it helps :)