- you need aligned incentives across the board. Sales and accounts mustn’t promise what the company can’t deliver
- people need to defend their area of expertise whilst listening to what others are saying about theirs. For me this boils down to a division between technical and business focussed. Techies need to push for non-client facing technical improvements without making everyone ignore them every time they say “technical debt”, and they need to accept that sometimes you just build shit to get business through the books. Sales/accounts need to accept that sometimes the build budget is taken up with mysterious technical drives that will be worth it. When I say “must accept” I mean accept that it must happen some percentage of the time - each case still needs to be backed up by a business case.
- ultimately this needs to come from the top - founder(s) must balance these facts and drive it through the whole organisation, and in the article they didn’t
I agree with what you’re saying. However given the reputation of openclaw (and I presume many other vibe coded spaghetti monsters) I appreciate the signal “I care about quality”.
This stuff is quite new to me as I’ve been learning F#, so take this with a pinch of salt. Some of the things you’d want are:
- a function to produce a list of customers
- a function or two to retrieve the data, which would be passed into the customer list function. This allows the customer list function to be independent of the data retrieval. This is essentially functional dependency injection
- a function to take a list of customers and return a list of effects: things that should happen
- this is where I wave my hands as I’m not sure of the plumbing. But the final part is something that takes the list of effects and does something with them
With the above you have a core that is ignorant of where its inputs come from and how its effects are achieved - it’s very much a pure domain model, with the messy interfaces with the outside world kept at the edges
Becoming a dad or are you already one and just upping the excitement? If you’re new, my two pieces of advice are that there’s only right now to deal with when things start to feel rough, and lick your fingers to open the nappy sack before you start dealing with the nappy. Both gems and hard-won
Woodworking and designing furniture. Just this weekend I finally set up my home workshop after almost a decade of dreaming about it (and collecting things I thought I might need). Just spent two hours drawing basic layouts for some wardrobes, and looking at beautiful midcentury, Scandinavian, and Japanese items online. Any good resources (for technical or aesthetics) are very much welcome - I’m looking to invest in my knowledge now I can put it to use.
This reminds me of something that always made me smile - when at uni I lived with an Israeli guy who made yogurt in a pan in the kitchen. When I asked how you make yogurt, the answer was “put some milk in a pan with some yogurt and leave it for a few days”. Not sure whether they’re in on the joke here, but the recipe for yogurt is to buy some
My dad was an audiologist and worked for many years with children with cochlear implants. I remember in the 90s him bringing a laptop home with software that tested otoacoustic emissions via a microphone/earbud combo. Later I met one of his colleagues from that time who, whilst working full time and with a large young family, obtained a phd in using this tech to test newborn hearing. That work has been the basis for the UK’s national newborn hearing screening service for decades now, helping to catch issues early where the most impact can be made. I’m really in awe of this profession - it’s pretty out of sight for many but makes a huge difference.
Re: data from another of your own systems. If there’s an interface between them that suggests you probably want those systems decoupled. Maybe in the future you replace one system with another you don’t control - ideally it would be nice not to have to make code changes because of that.
Re: asserting on user input. If you assert only then what happens on bad inputs when asserts are switched off in prod? Seems like an outcome you’d like to control at the time rather than allow to propagate (by writing bad data to a db and only being discovered months later, for example).
.net dev here. I started my career using Mendix. It’s very much aimed at enterprise (see pricing) and in direct competition with Outsystems. I haven’t used it for about two years now so might be out of date. Some unordered thoughts:
- I wasn’t around for the decision between outsystems and mendix, but apparently the choice largely came down to the support provided by the Mendix team in getting a fledgling dev team up and running in a company which at the time only outsourced dev work
- following on from that, the Mendix guys were all great to work with. A genuine positive. I heard that the impression of outsystems was much colder
- it’s a really mature product that’s always growing. Backed by Siemens for a few years now.
- like all low code it has its limits but it’s built in Java and there is the option to add Java code where needed for performance or for some other reason. There are APIs for hooking into the platform at multiple levels so it’s extensible.
- in my current job I build in azure/logic apps/function apps. Personally I would either do function apps or full low code like Mendix (costs aside). I try to avoid the middle ground or power automate/power apps/ logic apps - you basically get the worst of all worlds, and are only really intended to link services together or orchestrate amongst services.
Like this one [1], previously served to the Queen?
Sarcasm aside, I have now reviewed some articles on nutmeg intoxication (thank you) and will lower the amount I put on certain things - I love the stuff!
I personally find the subscription model in some ways better in terms of cognitive load - choosing between concrete things can be paralysing enough that the two most likely outcomes are failing to make a choice or choosing something and regretting it. The sense of now owning something that I spent hard earned cash on can feel a burden if money gets tight.
Subscriptions, on the other hand, match how consuming media feels to me - I spent time doing something I liked and the cost enabled that.
Looking on it from a pure economics point of view, clearly it makes more sense to buy a CD and have access to it forever from that spend. But psychologically it feels very different
- you need aligned incentives across the board. Sales and accounts mustn’t promise what the company can’t deliver
- people need to defend their area of expertise whilst listening to what others are saying about theirs. For me this boils down to a division between technical and business focussed. Techies need to push for non-client facing technical improvements without making everyone ignore them every time they say “technical debt”, and they need to accept that sometimes you just build shit to get business through the books. Sales/accounts need to accept that sometimes the build budget is taken up with mysterious technical drives that will be worth it. When I say “must accept” I mean accept that it must happen some percentage of the time - each case still needs to be backed up by a business case.
- ultimately this needs to come from the top - founder(s) must balance these facts and drive it through the whole organisation, and in the article they didn’t