| ▲ | lnenad 3 hours ago |
| As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by > “Do we really need that?”
> “What happens if we don’t do this?”
> “Can we make do for now? Maybe come back to this later when it becomes more important?” as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out new things would be different than a CRUD SaaS with 100 clients in a field that could benefit from a fresh perspective. There are definitely ways to have eager/very open seniors drive systems into hard to get out corners. But then there are people that claim PHP5 is all you need. |
|
| ▲ | bilekas 2 hours ago | parent | next [-] |
| I came to say somethign simular actually. > Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can. There are times when this is good, there are times when actively trying introduce an improvement is the best way forward. A good senior is able to recognise when those times are. |
| |
| ▲ | ericmcer 2 hours ago | parent | next [-] | | That doesn't sound as good in meetings. The person who can cut scope and get everyone to the "we did it" back patting phase makes everyone feel warm and cozy. Now combing through analytics to determine whether or not what we did was actually good? Less warm and cozy. | | |
| ▲ | hnlmorg an hour ago | parent | next [-] | | This is where good leadership in the dev team is needed. Is the improvement likely to reduce maintenance overhead (and thus cost)? Or improve performance allowing for fewer services running (and thus reducing cost)? Or reduce bugs that force people out of a workflow (eg in an online shop, thus fixing it increases sales)? Or if it’s just tech debt then use Jira (etc) to your advantage and talk about the number of tickets you can close of this sprint due to this engineering initiative. If the development team and product teams goals are largely aligned then the problem with engineering initiatives is just how you explain them to the product team. | |
| ▲ | hilariously an hour ago | parent | prev [-] | | For a large enough problem you need a combination of enough skill (to do the job), enough foresight (to know what likely will go wrong and how much error budget you need), and skin in the game (so you dont just cut things that sound good but instead what is truly needed) - if you don't have all three of these you usually are just talking out of your ass. |
| |
| ▲ | lnenad 2 hours ago | parent | prev [-] | | Exactly. |
|
|
| ▲ | hirako2000 3 hours ago | parent | prev | next [-] |
| A sort of survivor bias. A VP ordered to use elastic search, because it worked well at his company before. Turned out it worked well for us. Listen to the VP to make technical decisions. And use elastic search. |
| |
| ▲ | giancarlostoro 2 hours ago | parent | next [-] | | Reminds me when the ELK stack was called just ELK (idek what it is now) we had a server we put it on, and after making the additional dashboards my manager wanted, we learned the limits of ES / ELK. It needs a ridiculous amount of memory, because it will shove everything in memory. Same thing when I learned that MongoDB indexing puts every item in memory as well, which is a yikes, why would you not want to index? I bet there's money to be made for building a drop-in to either of those two that requires less memory, would save companies a bundle, and make other companies a bundle as well. | | |
| ▲ | hilariously an hour ago | parent [-] | | There's no high performance database that wont take all of your memory (at least for size of data) if you let it. That's because it's much, MUCH faster to do it that way, though if you can deal with certain type of latency trade offs for throughput something like turbopuffer can do wonders for your costs. | | |
| ▲ | giancarlostoro an hour ago | parent [-] | | MySQL doesnt eat up all 8GB of my system when I need to query a table with indexed values, MongoDB seems to eat it all up. | | |
| ▲ | hilariously 5 minutes ago | parent | next [-] | | If the data is < ram size and if you read that data again and its off disk again its the slowest it can possibly be, there's a reason most databases implement a buffer cache (actually making writes insanely faster as well) but yeah, MySQL is generally not a very good operational database with all the ones I have tinkered with. | |
| ▲ | vscode-rest 40 minutes ago | parent | prev [-] | | You paid one hundred bucks for that eight gb of ram, do you really want it to just sit there unused? | | |
|
|
| |
| ▲ | quantified 2 hours ago | parent | prev [-] | | Pick the right use case. It is super awkward, horrible UI for things like log analysis. Use Scalyr instead. |
|
|
| ▲ | sisve an hour ago | parent | prev | next [-] |
| Agree. context matter. As a senior developer you need to understand complexity, risk, upsides and and downsides. Understand the business side.
If you are a startup or a big company that is already a cash cow makes a difference when changing a core featrue of the product etc... context context context |
| |
| ▲ | Ferret7446 10 minutes ago | parent [-] | | One of the side effects of the LLM boom is that it made it a lot easier to tell people that context is important |
|
|
| ▲ | lwhi 2 hours ago | parent | prev | next [-] |
| I think you may be missing the message the OP is trying to communicate. The qualities were highlighted because they can all lead to better stability. |
| |
| ▲ | lnenad an hour ago | parent [-] | | Why can't innovation bring better stability? | | |
| ▲ | nine_k an hour ago | parent [-] | | Innovation is change, and change is the opposite of stability. Innovation can reduce pain though, if the current pain is strong enough. A stable stream of failures in production can be the kind of "stability" you want to disrupt. | | |
| ▲ | lnenad 5 minutes ago | parent [-] | | What are we talking about? Philosophically yes. Factually, no. In the context of a system innovation could be switching from one form that renders in 1 second to another that renders in 50ms. Stability isn't part of that equation. |
|
|
|
|
| ▲ | someone654 an hour ago | parent | prev | next [-] |
| Was thinking the same thing, but then i re-read the section and noticed this: > Yes, yes, of course this is simplistic. It's an example, put to the extreme, to clearly communicate the ideas. As all things, the golden mean applies, as I understand the article argues for: > the design of the 'Scale' version is influenced by what worked and what doesn’t work in the 'Speed' version of the system. |
|
| ▲ | dickywad an hour ago | parent | prev [-] |
| [dead] |
