Wednesday, December 07, 2022

Writing software is all about mastering abstraction.

 Writing software is all about mastering abstraction.

When modelling a problem in software you are always ignoring some details and representing others. Hopefully capturing all the ones that influence the desired behaviour of the system.
eg. Does Github need the weight of each developer? Will it behave differently for people based on that data? no? then no.. don't capture that aspect of the world.When modelling a problem domain, we frequently see a way we can 'think about the problem' ... usually some sort of analogy. Typically we do this to remove duplication (which is one indication that a useful abstraction may exist).
eg. So... when the users save the reports we could think of those as "save-requests" and "queue" them and have a "worker" "process" them all.
When we introduce that analogy to the code, then when someone is reading the code they have to now understand the intended behaviour of the system, and the abstraction we have chosen to use to help solve the problem.Every step we take away from describing the actual problem in code is a mental step the reader has to take to understand the solution. This is extra work paid every time you reason about the code. So... the abstraction has to have enough value to be worth including. eg. it make the code easier to think about or much faster to execution or more composeable....When we pick the wrong abstraction, the code is harder to read, harder to think about, and the building blocks are hard to assemble into the behaviour we want. They tend to have unintended side effects, and do extra work in-case it's needed, the slows down performance.Refactoring verbose code into some sort of abstraction is fairly easy.
Refactoring abstract code from the wrong abstraction to a better one is usually much harder.So... what abstractions do we have in our code? What do they make easy? What do they make hard? Are they helping us or getting in the way?

Thursday, August 18, 2022

There's something inherently satisfying about 'putting in the plumbing'

I think it's one of the things that makes highly productive developers. The ability to identify and remove friction from the things you do every day.

I like things I can rely on. So I make simple things that do one thing... then rely on them do to that thing for me, so I can think at a higher level of abstraction.I wrote a script to go grab all the env vars from an environment, so I can set up my machine to connect to that environment correctly.

I wrote a script to launch 'docker-compose -f docker-compose-localRemotedb.config %$'  so I don't have to think about it any more. ... then it grew... to include sending my ssh key.. and soon to set up the env variables for me based on the output of the other script 
:wink:Anything that makes me able to type what I'm trying to achieve and it does it... instead of telling the computer a series of commands to get it to do something. :slightly_smiling_face:

The natural extension of this is devops.  I want to just say "i'm happy with this" and it gets checked and rolled out for me.
When learning Lisp the language itself is so light weight... that if you want to do anything you end up making your own abstractions and data structures...etc.  so in effect you end up defining your domain specific language for the problem you are solving... then define your solution in terms of that language.This mindset of "this code is defines a concept" and "this code explains my intention in terms of that concept" is key to accelerating as you work.

If the concepts you create align with how your domain experts (customers?) talk about the business domain you are working in.. then the likelyhood is that your solution will be something experts can read and agree with.'s likely that when you learn more about the domain you will be able to refine your definitions of those terms and your code will keep working.
If you model someone's solution with a metaphore... like "So you can think of your customers as being on a conveyer-belt being dipped in different colors of products" .. then when your next requirement comes in.. you will probably have to drop the metaphore and re-write the code.

GitHub Projects