Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Laying myself off from Amazon

daniel.do

Post reply on HN
Print view View original

251–260 of 374 posts

Re: Laying myself off from Amazon

#251

Post by beebmam »

BurningFrog wrote: post #232
Patrol8394 wrote: post #79

Earlier quoted context omitted.

They all look shining from the outside, problems start when you join the new team and realize the pile of s t you will be dealing with. Btw this happens in most companies, tons of tech debt. And those who created that s t are off onto new projects recreating the exact same mess all over again. It is a cycle that never ends. Only chance is to join early and be in for the long run.

If you're good at cleaning up "pile of shit" code, you will always have work! It's s lot of fun with the right attitude.

I've made a great career of being a code janitor and doing what others don't want, while having a good attitude. In the last few years, I just rewrite everything I possibly can in Rust and I've yet to regret it.

Re: Laying myself off from Amazon

#252

Post by Haga »

BurningFrog wrote: post #232
Patrol8394 wrote: post #79

Earlier quoted context omitted.

They all look shining from the outside, problems start when you join the new team and realize the pile of s t you will be dealing with. Btw this happens in most companies, tons of tech debt. And those who created that s t are off onto new projects recreating the exact same mess all over again. It is a cycle that never ends. Only chance is to join early and be in for the long run.

If you're good at cleaning up "pile of shit" code, you will always have work! It's s lot of fun with the right attitude.

No post body was provided.

Re: Laying myself off from Amazon

#253

Post by silisili »

pbronez wrote: post #85
scruple wrote: post #41

Earlier quoted context omitted.

When I worked for a BigTechCo, I was doing exercism every single morning for ~30 minutes for the same reason. It really is incredible. I know a few of my former colleagues were doing the same. Today I'm on a team with 4 other engineers, so I keep busy coding.

Thanks for the tip - Exercism looks great. https://exercism.org/

Thanks for the link.

I initially thought it was a misspelling of exorcism, and OP was making a joke.

Re: Laying myself off from Amazon

#254

Post by nevon »

dimmke wrote: post #222
p0rkbelly wrote: post #186

Earlier quoted context omitted.

If your code breaks something, you should fix that code. Who else should? If your system/product/service is down because you have a dependency on something that broke -- well it's up to that team to fix their code.

This is the pat answer Amazon gives to defend this absurd practice, but it breaks down really easily. >If your code breaks something, you should fix that code. Who else should? What if it wasn't my code, but code written by someone 3 years ago who quit because most people only work at the company for 2 years? And it's in a part of the codebase I've never touched. That's a much more likely scenario.

That's still your code ("your" meaning the team that owns the product). Who else would own it? The person that left 3 years ago?

Re: Laying myself off from Amazon

#255

Post by rdiddly »

matai_kolila wrote: post #104

Sigh... another loss at the hands of, "Code is Art!" It's not art. Art requires no function, it exists as a representation. (Professional) code, and software engineering generally, must produce valuable things, and sometimes the process of making those valuable things isn't "fun", but that's never been part of the equation. Aligning "fun" with "valuable" is nearly impossible, and when you try you're dooming yourself…

There's no hard divide between the two. It's a continuum.

Re: Laying myself off from Amazon

#257

Post by shepherdjerred »

ksubedi wrote: post #242

I quit Amazon a couple weeks ago to start a startup, and I felt like I was reading my own story at some points. The tooling was the biggest thing dragging me back. It's hard to get excited about what you are building when you have to wait 2-4 minutes to preview your changes when most industry standard tools / stacks can do it instantly. I left this feedback a bunch of times with different people in the org and I real…

2-4 minutes????

Minimum 20 minutes to build my team's packages. Integration tests didn't run locally and you'd have to push. Same thing for LPT/CFN changes.

Tooling at Amazon is _incredibly advanced_, but no teams know how to use it properly.

Re: Laying myself off from Amazon

#258

Post by oaiey »

Zvez wrote: post #163
anyfoo wrote: post #135

I did not feel super sympathetic when reading the breakdown of percentages (with only 10% "actually writing code"). Yeah, those specific percentages were a bit egregious, but working on a big project it's not uncommon at all to spend more time thinking and talking things through than to actually write code. There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually eng…

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on. And at the same time the e…

The problem is essentially the following: in a know-all situation (prototype, reduced domain, startup,..) situation it is easy to ditch the 90%. No sync needed, no docs needed, no tests needed, ...

Once you scale up to large systems (ignore complexity) with hundreds of developers then you do and can not know it all. At that moment the churn starts.

And unfortunately, once you get big, regulators, lawyers, audits and other things become a drama as well.

Re: Laying myself off from Amazon

#259

Post by siliconc0w »

People focus on coverage but I think that has diminishing returns. There is a lot of 'art' to building clean reusable code which you can't easily standardize but what you can do is pay attention to things like:

* Build times * Testing times * Test Flakiness * High quality fast unit and integration tests * High quality fakes * Fast, high fidelity non-prod environments * Time from commit to production, number of cherry picks/rollbacks * Good Coverage, but focus where it matters.

If any of these go out of whack it needs to be a P0-P1 to fix because it really is debt that grows to become unmanageable (not to mention repelling to the best people).

In most companies, even big tech, this is difficult because non-coders set priorities and allocate the resources. Even once-upon-a-time engineers who make it up the org chart find themselves preoccupied with other things and invariably sacrifice these things for features, compliance, conformity, toolchain complexity/sophistication, security, outage/incident scar tissue, etc.

(And maybe rightly so as there are few successful businesses that manage this consistently)

Re: Laying myself off from Amazon

#260

Post by sumanthvepa »

nyarlathotep_ wrote: post #3

Worked for AWS for just under a year and a half; this mirrors my experience exactly. Poorly designed, failure-prone, brittle internal tooling was a time and energy sink to the point where even the most trivial deployment change was a nail-biter. Automated tooling and tests that were ostensibly created to make life easier were the number one pain point and constantly failed in obscure ways that required cutting ticket…

I worked at Amazon from 1998 to 2003. Those were exactly my experiences. Clearly they don't care about the internal development experience and probably never will.
Post reply on HN