ownagefool

  Pay - Almost always, wages don't keep up with your progression, and never with the market.
  Progression - Not just promotions, but being given the interesting work to run with.  Once someone sees you as junior, it's easier to go somewhere else to be treated with a bit more gravitas.
  Morale - Quite a lot of tech leadership is terrible.  Various problems make people sad.
  Skill - They might actually be terrible / or skilled but terrible at actually finishing anything.
  

I'm in the UK and spent many years as a contractor. It was never a case of not caring, or not wanting a long term home, and since most of the work and platforms were similar org to org, not understanding longer term consequences of decisions doesn't entirly apply.

Mostly, the negativity just writes off ambitious people. Though it might make sense given your org, like others, might just have the same reward problems.

There's also a bunch of lovely people. One of the companies I worked with had a remote office in Romania, and onshored a fair amount of staff, and they were perfectly european culturally.

The counter is obviously there's nothing wrong with Romanians ethnically, but there has been downsides of denying the negative consequences of immigration, which had helped fuel our absolute farce of removing from the union.

With that said, from the little knowledge I have on the issues, many of these issues are the UK shooting itself in the foot, but my point is these are not black and white issues, but rather complex issues that are better fixed for an increasingly stable Europe.

Like sure, you could ship a router, firewall, IPS, WAF, et all. But if you're not stopping outbound, controlling clients ability to talk to each other, and blocking things like UPNP, then you're still basically on an untrusted network.

Your options are basically make the network unuseable or mark it untrusted.

At that point you might as well just force all traffic through a VPN.

You can take my localhost from my cold dead hands :p

I could get behind the death of staging tho.

The type of company posting about getting hacked like this is probably using the root / admin accounts to do most things. Their lowest hanging fruit and biggest wins would probably MFA, then SSO.

However, IAM is generally powerful enough to allow you to configure what an account can do.

So best practice, you also want to think about how you're going to lose credentials.

- Sharing passwords across services - leak of your .dotfiles, either by having your laptop pwned, or uploading your .dotfiles to a public repo as a backup or something. - Accidently pasting into the wrong window or something.

SSO & MFA defeats all of these with exception that your sts token will be signed for 1h in those .dotfiles when you auth yourself. I'm not sure what happens if you remove it from the token from the device, but the device itself being compromised would allow someone to piggy back your session.

Ergo, you move to least privilege access, and then if your laptop, server, or ci/cd runner gets hijacked, then it's only able to do whatever it was allowed to do in the first place.

The last part is you need to detect the misuse.

When you have least privileged access, and a pretty locked down account, the hope is when a session is hijacked, the attacker will attempt to use the credentials and get an access denied. This should allow you to detect and remediate the reason for leak.

Obviously this turns your cloud install into a lot more work, and you still also need to look at maintaining and patching the actual services so they're not compromised in the first place.

Personally I think it's significantly better than what was common ( in the UK ) before, but the tech is dime a dozen, and new houses should probably come with underfloor, and control per room, though most still don't.

If you go back to a EBITA multiple, then moving away from expensive cloud providers might genuinely pump your value.

The real question is whether or not you have the tech chops or the willingness to invest in the type of people you need to do this well.

Downside is it requires you come up with a structure and a bit of discipline to maintain coherence.

If you use codeowners and your CI can include other files, then most of the downsides go away, besides the repo size itself.

Multirepo is a bit easier to understand per item. You can have one single CI file, and don't need codeowners, but you move a lot of burden to test, deploy and run.

If your SCM supports codeowners and CI supports includes, I'd stick closer to mono-repos, and only break out things when it's helpful a D you obviously wouldn't change together.

Think services rather than micro.

  Location: Norwich, UK
  Remote: Yes, or Hybrid.  Have my own Ltd, so can be engaged globally.  Would make a good satellite SRE for SV firms I think.
  Willing to relocate: For right role.
  Technologies: Cloud ( AWS, GCP, Azure ), Linux / On-prem, Various Programming languages ( Golang most recently, but some Python, PHP, Perl, C, Java, and more over various years ), kubernetes, CI/CD ( Jenkins, Gitlab, Drone, Concourse Actions, etc ).  
  Résumé/CV: 
    15 YOE Total
    ---
    2 YOE Scale-up CTO ( 19m ARR -> 75m ARR; No funding ).
    6 YOE DevOps Transformation.
    7 YOE Software Developer.
    Ask for CV.   Interested in both IC / EM.
  Email: allan+hnjobs@secureweb.ltd

Opportunity cost and all that.

My last gig had an MSSQL database component that pushed $700,000 a year.

It wasn't _that_ big but it was pushing the upper published limits of what you could do with an MSSQL RDS. One day replication stopped working, and amazon business support of whatever couldn't resolve it.

I've been around the block and have continuously come to the conclusion that it's usually better to have the skills to run them yourself, and then it's just a balance of whether or not you're time or cash poor.

- At the lower levels you're getting shit done. Maybe. And if you are that's good, but if the shit isn't revenue generative, supporting revenue, or saving costs, then your job might actually be a bullshit job.

- At the higher levels, you hopefully know where your revenue is coming from, and your job is to maintain that whilst growing more. But if you have no operational ability, you're at the mercy of the first group, and might not actually have any real impact in the direction of the company.

The mismatch and lack of empathy causes the discourse. The devs typically have limited incentive to chase revenue, the leaders have limited desire to get their hands dirty.

Successful startups / growth companies are less likely to look like this, though funding can distort the relationship.

In the UK the market is pretty dumb. Folks are mainly looking for reasons to exclude you rather than focusing on the positives. Ergo, I fire and forget resumes and only really put effort into the ones that come back positively.

When I get past the gate keepers, I almost always get an offer.

So my point is, "hang in there".

- previously passed a loop with FAANG ( didn't join tho ) - have a strong portfolio in a hard to resource niche

Easily send out 200 apps and get ignored.

The market is dumb, not sure I should quit over it tho

The BOM of Golang, which you know, is easily found:

https://github.com/Dominic-Wassef/ghostly/blob/main/go.mod https://github.com/Dominic-Wassef/ghostly/blob/main/go.sum

I suspect most library authors who are happy with others using their work, are probably somewhat okay with the standard file pointing to their original work as attribution.

It's also a bit more than 100 glue code.

Last paragraph is a good though. :)

I've worked in, and defined, secure environments where your only option is you need to raise another PR. For me this often degenerates into the PR spinning up a copy in another account, and the PR history being "test, test, test, ffs, test".

Like this: https://github.com/secureweb/homelab/commits/parca

The more practical way around the problem is to have non-production accounts where you can delegate admin, without the risk of the production and tooling accounts, and use that to make sure your code works before you actually raise the PR and merge.

It's prudent to remember that such security should be risk based, so whilst there's risk that you leak non-prod credentials to a crypto farmer, the risk of your teams being non-productive is greater.

Largely agree with you though. I usually just run k8s environments and make concession to use the cloud stuff when it makes sense. Not being able to run locally is akin to punching yourself in the nuts. Creating a namespace in k8s and deploying ephemeral tests either locally or in a dev cluster is better experience in my opinion.

But you do have a lot of folks who treat their cloud provider like their favourite sports team.

In general with any of the management consultants, you're going to get people with very little actual experience telling you how to run your company.

Whilst some of the stuff, usually more accountancy / factual based, doesn't require experience, and thus may be delivered to a high standard, you're also going to got a bunch of hot takes that don't make sense in reality.

Outsourcing, the Spotify model, and not really agile Agile are all sold by the top tier consultants, even though you basically can't name successful examples.

In practice, you manually bootstrap your CI/CD, and if you really want to be secret squirrel secure, you can audit that.

Everything going forward gets to be commited via code, peer review, least privledged access, and is automatically deployed by the robot.

At that point, you might hand out some break glass credentials for a few items, or when your CI/CD goes down, but usage of that should alert and be manually reviewed.

You now have a pretty decent setup, as everything is checked.

Like sure, slack / teams can see all your data, but if you have a trivial problem such as being in the EU, you suddenly now have a compliance problem if specific data gets put on the service.

Run mattermost on your own server and many of the problems go away.

Mastodon is a bit different because it's federated, but I assume since it's more akin to a social network, it's similar to running a community support website compliance wise.

if err := c.ShouldBindHeader(&headers); err != nil { log.Println(err.Error()) c.JSON(http.StatusUnauthorized, gin.H{"error": err.Error()}) return }

I don't think I give any more or less thought about it overall. Honestly, I'd probably rather just write the happy path, but still like the language either way.

The problem is the brand has been captured by consultants selling something that doesn't jive with the original ethos.

You were supposed to talk to the customers. Now you have dedicated POs that determine what the team will work on, but they're also too junior to talk to the customers. It's okay though, you have dedicated PMs that'll talk to the customers, right? Only they're typically to busy pushing a personal agenda to climb the corporate ladder to actually care.

It's cool though, we're agile so we can just change the process? Nah, there's now there's extremely prescriptive processes. Heaven forbid you don't find the hour long retrospectives, that you can't action anything from, useful.

So basically it boils down to the daily status report which ensures you a) show up on time and b) report on your commitments, and generally being forced to overcommit by committe on really short deadlines, so you can be pressured to work free overtime because apparently its your commitment?

Of course, not everyone abuses agile like this. But they don't typically advertise, sell, or even really talk about agile all that much.

My wife shared a house for a short period of time with an architect who was fairly new out of uni and did not know how to code, or have any real tech skills.

At the same time I was working for large companies in digital transformation trying to teach them to let developers make decisions.

It's common EA is about PowerPoint and talking to vendors with checklists, and doesn't require strong or sometimes any tech chops.

I find it crazy.

What if the client is compromised? Are we throwing away reviews? Should the reviewer re-run all the tests?

I don't think the delta to make k8s integrated is that much work with EKS, but ability to mutate the entire infrastructe if and when you do scale wins out for me. I think the complexity, most of which you can ignore, is worth the flexibility.

Either way, since k8s landed, AWS itself has started improving too.

When it comes to an actual companies personality, it basically boils down to the behaviour you reward, the behaviour you put up with, and when exceptions apply. As an example, how many time does the "no asshole" rule get overrides by someone talent? Suddenly you're full of assholes.

Of course patterns emerge. If the market generally rewards empire builders, then you're going to get people empire building in your organisation. Even if you do not directly reward it, they'll just leverage the title and the reports to land a job elsewhere.

Why do we put up with this? Well quite simply, you tend to be hiring for roles you yourself don't understand. Here me out. If your CEO is a sales guy, which is perfectly fine, he's going to be taking a leap of faith somewhere when he picks a CTO.

I read on linkedin on a regular basis that you shouldn't promote your best developer to CTO. There may be some truth to this, but the reality is that there's a bunch of non-technical people vying for the top technical job. Now from your position as CEO, do you pick the guy who's a bit more salesy and familiar, or the tech you don't understand or empathise with? After all, that CTO with 2 years as a junior programmer in 1993 does articulate a really good argument.

Personally, I think you doom yourself to mediocrity by having a monoculture of bean counters run your business. I might be wrong, but if you hire a person who needs to hire a person to do the job, it's likely they'll want to hire someone a bit like them, and suddenly you'll be hiring a person, to hire a person, that needs to hire a person, for many layers, until one of those people will be a person that does a thing.

Bit like this picture:

https://digitalsynopsis.com/wp-content/uploads/2019/02/funny...

Listen, I've been around the block and I understand it's quite common for the PM or other similar softer roles to be given leadership.

I've seen this to the point where they both recruit and promote the techs themselves.

What I'm saying is it doesn't have to be like this. If the PMs job is to find and articulate value, and the Engineers job is to produce said value, on a well performing team, it's a match made in heaven.

A poor PM with dominance over tech will happily torpedo the Engineers career with little emphathy whilst doing so, so why do we assume tech leadership should be in a different department?

My opinion is align the Engineer KPIs with value, which aligns them with strong PMs, but allow them the autonomy to say no when it makes sense to.

Just an opinion tho :)

Which goes back to the point, maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate, but not direct the others groups, whom are the actual experts of their respective areas.

How a feature UX should work based on the PM having a fair bit of expertise in the field? Maybe.

What task you work on next? Maybe not.

You see the problem with letting someone who's not an expert in the work decided the work goes both ways. The PM is in charge? Good luck getting patching on the backlog. Don't consult the PM? Good luck getting the functionality right.

My takeaway is the PMs often aren't the experts in writing, maintaining, or running a production system, thus they probably shouldn't actually run the backlog. But said production system is pretty useless without market fit, so you want to strongly align with whoever your version of a PM is.

Take for example the "can't define an array" crowd. Are there people virtually sitting in front of me who just forget the basic syntax? Absolutly, but given we a) tell them that correct syntax isn't dreafully important, and b) let them pick the language, a [] would probably suffice, I don't think it's a completely unreasonble ask.

Moreso, when we added a prestep of basic questions that one can google, the "can't define an array" crowd mostly disappeared. Sure, there may be some other causation there, but it's hard to hire a coder that you know, can't demonstrate coding.

Finally, anecdata, since we started coding interviews, the quality of developer is simply better. We have had internal debates about this, but the truth is, everyone is overall happier with what we're doing, and I'm a lot happier that false positives are way down.

I'm sure there's other ways of course. :)