HN user

mugsie

1,027 karma

Graham Hayes

Software / Infrastructure Architect @ Udemy

Previously: Principal Engineer @ Microsoft Azure, Distinguished Member of Technical Staff @ Verizon, Master Engineer @ SUSE Senior Engineer @ Hewlett Packard Enterprise

ex - PTL for OpenStack Designate (DNS Project) (https://docs.openstack.org/designate/latest/)

ex - Member of the OpenStack Technical Committee

[ my public key: https://keybase.io/grahamhayes; my proof: https://keybase.io/grahamhayes/sigs/-W5bXnllXeYREBziC7KFYkLfh0caT8KLU6d7mQ20Tdw ]

Posts4
Comments330
View on HN
iTerm2 Web Browser 10 months ago

it would generally be for environments where the browser is locked down as well, or has a special extension installed for "security". In a lot of those cases the shell is recorded and send to a central tool, but the webview would not be logged

Code reviews kill velocity

Yes, they kill your velocity. However, the velocity of a team can be massively increased by shipping small things a lot more often.

Stable branches that sit around for weeks are the real velocity killer, and make things a lot more risky on deployment.

Why not require two or three reviews if they are so helpful at finding mistakes?

Places do? a lot of opensource projects have the concept of dual reviews, and a lot of code bases have CODEOWNERS to ensure the people with the context review the code, so you could have 5-10 reviewers if you do a large PR

Who handles physical security and what sort of place is it located that it can house that kind of data?

In general, the cloud/systems operator, in conjunction with the launch customer will build a dedicated facility for the classified stuff, and for the controlled stuff may have a dedicated facility, or have segments of the DCs in the US with extra security. for the classified stuff, there is a pretty rigorous list of requirements for the DC, and for any NOC that operates the service.

To what degree is the federal government subsidizing Amazon's retail dominance?

A fair bit, but they are just like any big customer - just with higher margins. I think that was part of the reasoning for breaking up JEDI after AWS got it - the administration at the time hated the AMZN leadership, so wanted to remove money firehose from them and give it to others.

apparently? JEDI and Wild and Stormy were two programs just from the DoD and NSA that were 20 billion USD.

AWS, Azure, Oracle, SUSE (via Rancher) and I am sure GCP all have confidential & classified (C/S/TS) clouds, as well as lower FedRAMP clouds to get that sweet sweet federal money.

Not sure what questions it raises, it has been a thing for decades.

If humans can't scale to review, how are they scaling to code? Humans how code should review, or the whole point of code review is pointless, and everyone should just push to HEAD and revert on failure

I was only there for a year or two, but it was a great place to work, and I 100% agree on the upstream contributors, but the main thing I will remember is how much people cared.

In some cases, waaayyy too much about little things, but a lot of the time about the right thing to do for the product and for the open source community around it.

I think the main thing I will miss is sitting down on a Friday afternoon and reading the dev list (devel@ I think?), it was a thing of beauty.

Yeah, DevOps was a culture not a job title, and then we let us software engineers in who just want to throw something into prod and go home on friday night, so they decided it was a task, and the lowest importance thing possible, but simultaniously, the devops/sre/prod eng teams needed to be perfect, because its prod.

it is a wierd dichotomy I have seem, and it is getting worse. We let teams have access to argo manifiests, and helm charts, and even let them do custom in repo charts.

not one team in the last year has actually gone and looked at k8s docs to figure out how to do basic shit, they just dump questions into channels, and soak up time from people explaining the basics of the system their software runs on.

Yeah, that doesn't really answer the question at all... Do you just have a pile of cloudformation on your desktop? point and click? tf? And then none of the actual questions like

How do you handle application lifecycle concerns like database backup/restore, migrations/upgrades?

were even touched.

Yup, and it has the advantage of having a easily backed up state store to represent the actions of the GUI.

I always liked the octant UI autogeneration for CRDs and the way it just parsed things correctly from the beginning, if they had an edit mode that would be perfect

Thats great if that works for you, and for a lot people and teams. You have just shifted the complexity of networking, storage, firewalling, IP management, L7 proxying to AWS, but hey, you do have click ops there.

DevOps went from something you did when standing up or deploying an application, to an industry-wide jobs program. It’s the TSA of the software world.

DevOps was never a job title, or process, it was a way of working, that went beyond yeeting to prod, and ignoring it.

From that one line, you never did devops - you did dev, with some deployment tools (that someone else wrote?)

Yeah, for a lot of companies, this is way overkill. Thats fine, don't use it! In the places I have seen use it when it is actually needed, the controller makes a lot of work for teams disappear. It exists, because thats how K8S itself works? - how it translates from a deployment -> replica set -> pod -> container.

Abstractions are useful to stop 100000s lines of boiler plate code. Same reason we have terraform providers, Ansible modules, and well, the same concepts in programming ...

it may be, especially if the ISP in question just does direct peering with you, your unit cost can drop to ~ $0/MB, and you stop paying Cogent/Verizion/HE unit cost for facilitating the connection from you to the ISP.

Works for the ISP too, one off cost for them to drop there side of the bill down

Vancouver Special 4 years ago

I have had quite a few sleepless nights in Vancouver over summers, and I don't live there, so I must have hit a heatwave every time I was there ....

I would also allow for apex load balancing, weighted load balancing, and failover without needing someone like cloudflare / akamai / a glb, all using standards

I think it's unfair to blame either party for this.

For the firing / termination of contract? Sure, everyone sucked.

For termination tagged with a reason that meant that the OP was blacklisted, and interfering with them being hired by another team? HR and the manager definitely are to blame, and should be called out for it.

I would say definitely - the OP did fail to manage up properly.

I think it is less of a part of the role for a senior engineer - Principal and over it is pretty much a core of your role - but it is something you should be doing.

The groundwork for doing it effectively comes from both sides however, and everyone sucks here for that.

I mean, sure, but they are not paid more because they are code monkeys, they are paid more because they have less stable employments, and in europe at least have a lot overhead costs they are responsible for that the employer would normally pay.

From the sound of it, Spotify was treating them like employees - most places would definitely not have contractors do hack time, or put code monkey contractors in the path of major feature estimations

As a contractor he should have STFU and done his job. His job is to do the work he's told to do.

or, told another way: dance monkey, dance.

If companies or managers just want to do the infinite monkeys typing shakespeare approach with 0 critical thought, don't hire / contract senior people.

Someone who doesn't push back on giving an estimate for something they have never seen is useless in a senior role. Sure, the kanban stuff might be a little out there, but if a manager is doing a shit job of blocking tasks mid sprint, again it is better they try and suggest something to help their co workers.

Sounds like the manager was in over their head.

Engineering team will always have items that are very hard to estimate without doing background work.

A good manager would have said "what do we need to do to figure out times?" and then "Can we timebox that research to a sprint / two sprints / etc?" are reported the horizon one timescale up.