Anyone who claims to teach paths by which to optimize Developer effectiveness ought to cite data to support those claims. Until data exists to contrast the results of Company A vs Company B, we'll never be short on speculative articles.
Maximizing Developer Effectiveness
11–20 of 168 posts
Re: Maximizing Developer Effectiveness
#12Ooph, just reading the highly effective vs low effective environment bullet points was triggering. I can think of environments I entered where a good chunk of it was highly effective and my most recent startup was plagued with the low effective one (and even then - it will still IPO). Worst part is - they really had no interest in improving it. To improve would require an entirely different management chain - one that didn't learn all their ideas in the 1990's from watching rocketships take off...
I sometimes wonder who these articles are written for. Am I supposed to share this with the CTO to show them how poorly the organization is being run? No, obviously not, that'd just fast track my firing. After all - if you're in an environment of psychological safety where you can air these issues then you're probably going to not have these issues very much.
Re: Maximizing Developer Effectiveness
#13> There is an overwhelming amount of good advice, practices, tools, and processes that you should use to improve. I disagree. Advice is contradictory, practices and processes are often orthogonal, and tools quite literally don't exist. I say this as someone that's worked in large companies and saw how lengthy not only process feedback loops were (especially developer ↔ product team), but also engineering feedback loo…
> It's not surprising that FAANG often designs their own internal systems that handle this sort of thing
This is one reason why I've loved using Notion. I maintain a few open source repos, and our team's process has grown organically over the past few months. Being able to use a Kanban board for one set of information, then decide that it's just better as a bulleted list; storing meeting notes from quick bullet points up to detailed step-by-step guides on how to fix some issue people had that week...
The low friction to high flexibility combo is great!
Re: Maximizing Developer Effectiveness
#14A) Short-term mindset developer:
- Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion.
- If it works, it's good enough. It does not matter if I can't explain why it works.
- Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks.
- I do exactly what I am asked for. It does not matter if it is insecure, it does not scale, or if the entire system crashes. All of that will be someone else's problem later.
- Code does not have to make sense, as long as it runs it is good enough.
- I worship project management.
B) Sustainable mindset developer:
- The cost of tech debt compounds over time. I should fix tech debt before more code depends on it and becomes more expensive to fix.
- I need to understand how and why things work. Is this really working? Do I really understand what I am doing?
- Reviewing relevant documentation for the technologies I use is a good idea. Making sure I understand and follow coding standards is a good idea. Well crafted coding standards can save work.
- I understand that not all stakeholders are technical. I need to understand the technical implications of what I am asked to do, and push back if necessary.
- Code is written once, read many times. Readability makes everyone more productive.
- I acknowledge that project management documentation and tools are a form of documentation, and as such, it is not a source of truth. When it comes to things to do, the implementation is the source of truth, not tickets.
Bad companies promote A), good companies promote B).
Re: Maximizing Developer Effectiveness
#15> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the ba…
They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith.
I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever bullshit - they decide to breakup ownership by github repo.
I'd love to be sold on it otherwise but that's what I've been told directly as the reason for the move to microservices by many companies and what I've seen at my own. Can't do a good job because your business practices suck? Fuck it - microservices, baby!
Re: Maximizing Developer Effectiveness
#16Anyone who claims to teach paths by which to optimize Developer effectiveness ought to cite data to support those claims. Until data exists to contrast the results of Company A vs Company B, we'll never be short on speculative articles.
Sure, but if you're a consultancy, like Thought Works, you're under watertight NDAs on everything. I work for a consultancy that helps and assesses companies too, some of them selling for north of a billion. We can share general, anonymized, observations, and I would argue some of those are very valuable simply because of the breadth of situations we get to see. But we legally can't cite specific instances. That's the biz. :-/
Re: Maximizing Developer Effectiveness
#17> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the ba…
They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever…
I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence.
For less centralized organizations, I think it can be a useful forcing function.
Re: Maximizing Developer Effectiveness
#18> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the ba…
I haven't found many articles from respected sources that will convince management that microservices are a bad idea.
There's https://martinfowler.com/bliki/MicroservicePrerequisites.htm... , but this won't convince them.
Re: Maximizing Developer Effectiveness
#19A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion. - If it works, it's good enough. It does not matter if I can't explain why it works. - Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks. - I do exactly what I am asked for. It does not matter if…
There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.
Re: Maximizing Developer Effectiveness
#20Earlier quoted context omitted.
They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever…
I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence. For less centralized organizations, I think it can be a useful forcing function.
Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django).
I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.