2,306 karma · joined December 16, 2012
Writing a decent Dockerfile isn't hard, and keeping it maintained and working with new versions is still work and it's past the wheelhouse of very many people. It's entirely reasonable to want paid for that effort.
That said, it's not work I personally value enough to put my hand in my pocket, and that's a fair take too.
My opinion is reality is more nuanced. Both "the code is self documenting" and "the code is the design" are reasonable takes within reasonable situations.
I'll give an example.
I work in a bureaucratic organization where there's a requirement to share data and a design doc that goes through a series of not-really-technical approvals. The entire point of the process is to be consumable to people who don't really know what an API is. It's an entirely reasonable point of view that we should just create the swagger doc and publish that for approval.
I worked in another organization where everything was an RFC. You make a proposal, all the tech leads don't really understand the problem space, and you have no experience doing the thing, so you get the nod to go ahead. You now have a standard that struggles against reality, and is difficult to change because it has broad acceptance.
I'm not saying we should live in a world with zero non-code artifacts, but as someone who hops org to org, most of the artifacts aren't useful, but a CI/CD that builds, tests, and deploys, looking at the output and looking at the code gives me way more insight that most non-code processes.
Like you're talking about fairness, but you're also arguing that other people should pay taxes to give your parents money, in order for them to keep their property, whilst many of those paying their taxes, will never get on the ladder, and if they do, will never afford such a lovely house.
Where's the fairness in that?
Further, most folks are aware of equity release and your parents could borrow against the house and not move. The main outcome is you wouldn't get it. Now I've bought such a house but I didn't get it from my parents, I got it by earning the money which I've paid income tax on, so it's literally required 2-3x in earnings to get there.
What's fair in that?
For the record, I have a kid in private school and will try my best to pass on as much as possible, so I totally get both your parents and your own position. I'm just poking fun on "fairness" because fairness in politics never seems to consider the person the money comes from and when you consider all angles, it's rarely fair.
This isn't to say taxing wealth is actually the solution, but it's the catch all that people like to scream about.
30% of pensioners are millionaires in the UK, and they recieve a state pension. Fixing that would probably immediately turn a massive budget surplus ( albeit a nasty suprise for financial planning ).
However, suddenly if you find pensioners releasing funds from their property, you affect what's going to be inherited and that's a no go area. There's no real concept of fairness in the debate, just the politics of it all.
Don't get me wrong. Correctness is a great default, much easier to reason about.
Sending webhooks, as an example, often has zero need to go back and update the database, but I've seen that exact example take down several different managed databases ( i.e., not just postgres ).
However, I've been in several situations where scaling the queue brings down the database, and therefore the app, and am thus of the opinion you probably shouldn't couple these systems too tightly.
There are pros and cons, of course.
That's where many of the practical issues come in of course.
I'm not going to personally argue they're not solvable, but many people will argue the requirements of basic shelter and sustenance being far higher than what they actually are, and in our current system, the landlords would take the cash anyways.
Of course, if we all end up jobless due to robotics and AI enhancement, which again isn't something that's necessarily going to happen, UBI or similar might be the only positive path out of that mess.
I'm just not at the stage in my life where I'm willing to onboard to a transformation that starts with a half a day call authenticating so you can login to a remote VM to do your development.
Similarly I had a 2 week gig where they send me some shitheap of a windows laptop that takes 20 minutes to login, where they wanted future engagements.
Nope. Nada. No way.
You can see the value of your productivity straight out the gate. It's not valued and you will never be able to change it from your vantage point of IC or middle manager.
It doesn't really matter that they say otherwise, the evidence tells the story.
> The boss wanted to scale but did not care about tech... We saw revenue grow a ton.
Sounds like the boss was largely getting the scaling they wanted?
Every situation is different and there are people with way more experience than me here, but in general terms I've seen the "we need to rewrite / write a component library" from immature tech. Problem is, they're never satifised, so after they're happy and they've moved on, the next person will say the exact same thing.
That's not to say your code didn't have real problems.
But experience tells me that there's tons of well written projects with no users or revenue, and lots of broken shit making money hand over fist. All else being equal, unless you're in a bubble, you're better off with the money.
( Not intended to imply the job wasn't terrible and the product didn't have real actual scaling problems making your life terrible, I've seen that too ).
You can also use just use cgroups with systemd.
Now, you could implement something fairly similar in each OS, but you wouldn't be able to use the vast majority of contained software, because it's ultimately linux software.
Honestly it's 30-45 minutes where you can establish whether the person can code, and whether they have the basic foundational knowledge to crack efficiency problems is pretty hard to beat.
Whilst there's probably diminishing returns on making the actual challenge more and more difficult, the general concept is a lot fairer than the majority of other interview types I've had thrown at me. ( Usually something they've solved internally, where they expect you to regurgitate the same answers without the same context )
When you have a single smallish schema, you export, restore, and write automated tests that'll probably prove that backups in 10 minutes ( runtime, development time few days / weeks ). Either the transaction runs or errors, and either the test passes or not.
The problem when small is obviously knowledge, skills, and procedures.
Things like:
- What if the monitoring that alerts me that the backups are down, is also actually down. - What do you mean it's no longer "safe" to kubectl delete pvc --all? - What do you mean there's nobody around with the skills to unfuck this? - What do you mean I actually have to respond to these alerts in a timely manner?
The reality is, when the database is small, it typically doesn't cost a whole lot, so there's a lack of incentive to really tool and skill for this when you can get a reasonable managed service.
I typically have those skills, but still use a managed service for my own startup because it's not worth my time.
Once the bill is a larger than TCO of self-hosting you have another discussion.
Killing shitty meetings, including the standup, was one of those dissenting opinions, obviously.
Here's another.
PMs, or any other role that abstracts the developers from value, serve to infantilise the developer. Instead of owning the most expedient way service a customer or generate revenue, they're instead owning the minutia of frameworks, architecture, or tooling.
Of course, you can still make an argument for the PM via efficiencies and skill specialization, but when you effectively give a non-technical person control of what the team works on, you in many circumstances no longer have a person with a view across both commercial and technical realities.
And whilst there are many ways to try and plug this gap, like Engineering Managers or arguments like you're holding it wrong, where exactly are these tech leaders learning those skills when in the vast majority of teams the PM keeps them in the dark? Thus, propagates the cycle where the technical are not commercially mature enough to make business decisions, which necessitates the need for adults in the room.
Point being, it's a trade-off and there's circumstances where the trade-off makes sense, and others where it doesn't.
If we put people over processes, you might actually find you can manage a much bigger org. Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option. The fact that that's sacrilege and constantly evokes the no true Scotsman tells you all you need to know about people over processes.
I did a stint with a large US org where my SOW was to do azure (hashicorp) vault. The org already had about 20 aws vault clusters, GCP was a likely new target.
I sold k8s. That was seen as risky despite being less overall work, so I delivered direct on azure clusters, then was given a SOW to do k8s POC ( with a view to doing GCP ).
POC delivered a fairly production like service in ~a week using the most junior person on the team, only to spark outrage that I ( a person with about 10 YOE with k8s ) had delivered a POC without discussing with the core platform team ( which was intended to be POC 2, separating the issues of concern ).
Now I get why people do platform teams, and this platform wasn't bad ( more work than rolling my own equivalent; but the processes in theory ensure the less experienced people don't do terrible things ).
End result was pretty much a blocker on GCP vaults because we were awaiting said platform team to deliver for us, and me ( a contractor that delivered several at risk SOWs ahead of schedule ) cut loose because we're blocked by the other team.
In such an org, it's the job of the EM to advocate for their delivery stream, mine didn't quite manage it that day.
However, this org was probably the best ran at scale I've ever seen ( usually you can nuke an org in like 10 minutes after they give you access to the SCM & CI/CD ).
If the parent leans on the hard earned skills to make better decisions that improves outcomes for their team and by extension the org, then it's entirely possible it makes them a better manager.
Where it gets complicated is questions non-related to this:
- Who and how is anyone measuring outcomes? This is often very difficult in abstract.
- Is the org actually setup to allow these teams to flourish? Will the measurement be fair, or is there effectively internal sabotage?
- What's the reward for being better? Would the parents life actually be materially better for making the effort?
Personally, I agree with the parent. On average, having good ICs making your IC decisions lead to better outcomes. Where there's grey areas is there's more than 1 way to structure this. Player managers are definitely valid. Better than non-technical managers with good soft skills making poor engineering decisions over and over.
Where I'd disagree is the continuous effort. Once you've reached a certain level, a lot of what happens below syntax. Occasionally you end up managing something you don't understand with contention in the team.
At this point, you either invest or defer. The problem with the latter, in my experience, is very few devs have experience with commercials, so most of the arguments are based on laziness, interests, or purism, rather than outcomes.
For the record, whilst there's managers we like working for, if they're not able to extract reward for business outcome for the few that chase that, are they actually any good?
I've seen this plenty of times.
Recently I was trying to explain the pros and cons of micro-services, and more importantly, microrepos, with regards to automated testing. The lead engineer that said he'd quit if I colocated the tests with the app.
Same place, they replaced all deploy system with argo, but every environment is pinned against main, which means you can no longer test a change without it going to all environments at the same time.
In both cases, the engineers are actually much higher skilled than average and churn out / lead change, but they'd rather be chasing a fad and just don't care if their changes shit on other parts of the SDLC.
At least some of these lists will be created to define the scope of the good engineer so it applies to them, or habits they like, but there's nothing that actually clarifies the benefit here. Is there a measurable increase in revenue, feature releases, uptime?
I've worked as a contractor for a decade. I'm brought in to deliver specific outcomes by specific timelines. There are polarizing views on what I do. Some will view me as the 10x engineer; others a bit of a cowboy.
However, there's no lack of "good engineers" that aren't able to deliver working software in a timely manner, which is why I'm even at those orgs in the first place.
However, I ran kubeadm on a hetzner server and it's just sat chugging along forever basically. I use the cluster to run ephemeral apps where I build and deploy 1 golang service, a couple of node services in about 60 seconds ( with cache, obviously ).
As someone old enough and skilled enough to do the same with puppet, why bother when it's simpler easier that even the kids who don't understand TLS can do it with k8s?
Etcd requires 3 boxes for HA, but nothing stops you running a single node etcd.
I personally run single master clusters, because if the master goes down, you lose management as opposed to actual service availability, so mostly I don't care.
Now that there's anything wrong with your preference.
With k8s you can easily install a bunch of helm charts and get a bespoke platform that becomes a full time role for multiple people.
There are pros and cons against this approach but you if you're worried k8s is complex, just use the cloud native integrations.
In the last 6 months my job has been to get production ready vault instances on azure. There's a bunch of complex, unreliable and not very fun APIs here.
Much like AWS, there isn't really a StatefulSet ( PetSet ) abstraction. To you need to write a bunch of bespoke logic where you figure which IP addresses, names, IDs, and Disks you need to attach to a new VM.
Whilst iterating, the azure APIs are eventually consistent that cause all sort of niggly problems. Resources that are created don't get added to TF when there's a failure.
I create a new vault on a PR and it takes 20 minutes to deploy.
The problem took a couple of months and I created a bunch of code.
On k8s I can just deploy the helm chart in 2 minutes. The abstractions are cleaner, it's more reliable, and way more fun.
At the end of the azure project, the team agreed to do a AKS poc, where we gave the task to the junior of the team, and the entire thing was done in a week.
If you're not doing this type of work, maybe you don't need k8s. But if you're not doing ephemeral test environments, do you actually not see them as a positive, or is it an effort thing? Because it takes me no real effort.
The problem is, all those outcomes exist with hiring your own developers, and it's really difficult to mitigate unless you yourself are a strong developer who can run projects and teams and look beyond what people are telling you.
Reality is, it's impossible to answer the question without really getting more information. Specifically around what you spend on outsourcing / licensing, what the feature set you're going, what the budget for the new team would be, and what the expected outcomes and timelines are.
Without the context though, some quick fire opinions.
- You probably at least want the dry powder. i.e. the person making the outsourcing decisions should at least have the technical accume to bring it in-house if required. If they're not a person that could, then outsource is the only decision they can realstically make, then they'll tell you it's the right decision even when it isn't.
- You need someone mature. If they just want to build everything from scratch always because of some personal bias, you'll end up amassing tech debt in areas where there were limited risk / benefit. Developers will 100% tell you you need to building things because it's interesting to them, even when you don't really need it.
- If you're going to do this with any near-term success your first hires are really key, and they likely won't be cheap. I see people debating brining in a team vs a CTO, but both strategies fail if the quality isn't there. Figure out how to validate quality.
I was CTO of from ~25m to ~£75m ARR UK Point-of-Sale org with ~100 tech employees. Those roles are hard to find. This sounds like a great opportunity. Lots of folks will likely do the hard sell. Good luck.