nibblebit

joined 2 years ago
MODERATOR OF
[–] nibblebit@programming.dev 1 points 2 years ago* (last edited 2 years ago)

I can tell having ai write small scripts and translating formats has made it more difficult for me to recognise the small differences between languages. I can tell i often get confused about how to do simple things like for loops http requests and file Io in c#, kotlin, rust, go , JS, pwsh, bash, Lua, pythong, groovy etc..

It's not necessarily a bad thing, but it is noticable the languages make less and less of a difference..

Edit: I think it's a similar thing as having a full featured ide with tons of code completion and suggestions. When writing stuff from scratch without prompts you kinda get lazy.

[–] nibblebit@programming.dev 1 points 2 years ago (1 children)

That's interesting. One of the problem for onboarding new engineers is they miss any domain knowledge of our product and building that end-user sensitivity is difficult. Embedding devs with sales,support etc does address this.

What are some problems you've experienced with this approach?

[–] nibblebit@programming.dev 26 points 2 years ago (1 children)

It's difficult problem to solve. Lemmy's stack is a bit unconventional. The rust backend is not idiomatic and the ui is based off a template of an isomorphic not-quite-react framework. Its not impossible, but it will take a while for alot of programmers come onboard.

That being said, there's more to it than writing code. Better bug reports, reproduction, updating docs and triaging/managing the issues is possibly more important than writing PRs. Don't be discouraged!

[–] nibblebit@programming.dev 2 points 2 years ago

I'm responsible for the engineering department at a midsized SaaS company. In the last two years, we grew from 5 to 20 engineers. We have divided our landscape in separate domains, each treated as a separate product with an API that the other domains interact with. Each domain has a dedicated development team. The end-user domains have POs assigned and the more platformy domains take requests from the other teams.

We lean heavily on automation. Each team is responsible for the development, quality control, security, delivery and monitoring. We don't have a dedicated DevOps or IT role but lean on fully automated self-monitoring systems.

We keep growing and we see that the need for specialisation arises. I'm not one for mandating a certain structure and procedure top-down, so the tools I mentioned above have helped us map out how our org has grown organically so that we can detect human bottlenecks. This we can make the boundaries of responsibilities clear and make choices that minimise the amount of 'syncing' and maximise the amount of decision-making.

Right now I see that the need for dedicated security officers, IT pros, DBAs, and analysts is starting to arise simply because full-stack devs' skills are limiting. Still, I'm unsure if it's best to reinforce the existing silos with specialists, or have a team of specialists that the rest of the org can turn to.

I also see that the complexity of our ecosystem has made it a challenge to onboard new young engineers. Additionally, the separate domains give the teams a great amount of autonomy. Our metrics show that this has dramatically improved the stability of our products in the long term. Still, it has made it more difficult and laborious to organise projects across teams.

These are just a few of the challenges I'm thinking about. Our situation obviously does not apply to everyone, but I am fishing for ideas from people in similar situations or who have seen this phase before. In my experience, every software org has unique challenges and unique solutions with unique outcomes, but I'm certain ideas could inspire other experienced programmers :)

[–] nibblebit@programming.dev 1 points 2 years ago (2 children)

Hey, if the answer is: there's no obvious solution, than at least i don't have to feel too bad 😂

[–] nibblebit@programming.dev 3 points 2 years ago

Withought being facetious. It's genuinely important to understand what problem you're trying to solve. If stakeholders are running wild, then critical thinking and good communication is important. If engineers are muddying up progress, then more optimistic and enabling mindset, could be what's needed more.

[–] nibblebit@programming.dev 2 points 2 years ago (1 children)

It depends...

[–] nibblebit@programming.dev 2 points 2 years ago

Article is a bit dated and hard to read. The gist of the author is relatable though 15 years later: redundancies have been hella annoying, especially if they are unknown. Bad abstractions, however, create dilemmas, dead-locks and chicken-and-egg situations. And it's impossible to create good abstractions unless you have no colleagues and no customers.

I would take some frustration over grinding to a halt any time.

[–] nibblebit@programming.dev 8 points 2 years ago* (last edited 2 years ago)

IT operators and DevOps engineers have been a nightmare liability for security, governance and business continuity. The best-case scenario for a DevOps/IT operator is that you get a superhero that does everything and knows it all. All responsibilities and security privileges gravitate towards this role, and knowledge sharing becomes impossible. Lastly, it becomes impossible to track the thousands of out-of-band changes initiated by a DevOps team to an auditor or certifier.

Cloud engineering, feature management and IAC tools have made it way better for engineers to build and deploy self-monitoring systems. A modern software ecosystem can be deployed, updated and migrated on an automated schedule. It can be done, safely without any of the responsible engineers having direct access to environment secrets or sensitive data. All of these changes can be set under version control for auditing purposes. If given the option, any smart employer would prefer the option to invest in such a system rather than support a 24-7 response team.

There will always be a need for surgery on a production environment, but there's no reason that can't be a formalised incident. If you are having weekly incidents that require engineers to do operations work, then that's something that needs to be addressed.

We should all be working to eliminate operations work. IT operator needs to be a trusted security role, not a critical glue with all the keys that holds a system together.

view more: ‹ prev next ›