Earlier quoted context omitted.
"Psych" not "sike" please people! It's short for "psych out."
Huh, I always figured "sike!" was the slang version. I have to say, I feel like "sike" says something that "psych!" doesn't.
Maximizing Developer Effectiveness
141–150 of 168 posts
Re: Maximizing Developer Effectiveness
#142Earlier quoted context omitted.
Huh, I always figured "sike!" was the slang version. I have to say, I feel like "sike" says something that "psych!" doesn't.
Yeah that was intentional. It’s weird to write “psych!”
Re: Maximizing Developer Effectiveness
#143Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…
Re: Maximizing Developer Effectiveness
#144Earlier quoted context omitted.
But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices). But that never seems to happen. I think it’s because codebase discipline rules are harder for managemen…
> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? 1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv. 2. After a decision is made, you'll have to decide on how to put the rule in place. Are you go…
Re: Maximizing Developer Effectiveness
#145Did anyone else notice that there is no software engineering management involved in the "ideal" picture? In this ideology, every developer acts autonomously, even by deploying to production. This removed all technical responsibilities from the well-payed management people. Conflicts? Resource management? Scheduling? Happens to other people. At the core of this ideology lies the principle that every software is just a…
Re: Maximizing Developer Effectiveness
#146Ooph, 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 tha…
>> I sometimes wonder who these articles are written for. If you're a Leader (big L) in an org, this gives you a way to asses your organization. If you're a leader (small l) it may give you a way to concretize your thinking around problems so you can discuss them better. >> Am I supposed to share this with the CTO to show them how poorly the organization is being run? That would be the worst way? Why don't you pick w…
Re: Maximizing Developer Effectiveness
#147Earlier quoted context omitted.
Asking for advice from a contractor is not bad. Asking for leadership from a contractor is bad: 1. They don’t understand what you need or how to get it to you, but they sound like they do, and they look professional. 2. There are no great contracting options for something you can’t do yourself and that there aren’t requirements for. Fixed contacts may start off looking good but they swap resources out and you end up…
Maybe. Funnily enough I was a contractor providing leadership and helping orgs for the last 5 years. I did my best to varying degrees of success because the leadership themselves would either let you run with it or not. My 1 man band is very different from thoughtworks though. Now I am leadership and it's way easier to just make decisions.
But if you don’t understand the requirements, choose to pay someone to figure it out, and they finger-paint your business, you may have been better off without it.
Nothing sells better than crap. By that I mean literally nothing, like you could sell emptiness more feasibly.
Re: Maximizing Developer Effectiveness
#148Earlier quoted context omitted.
Can you expand on "any rumor hire cheaper labor"? Im too new to understand that one.
"Now that you're all working from home anyway, I might as well outsource your job to India! That will save me a truckload of money too!"
Re: Maximizing Developer Effectiveness
#149Earlier quoted context omitted.
> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? 1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv. 2. After a decision is made, you'll have to decide on how to put the rule in place. Are you go…
None of these problems are solved by microservices. Now instead of undocumented unstructured interactions between modules, you have undocumented unstructured interactions between standalone applications. None of your problems are solved, except now you have a much bigger cloud hosting bill.
Microservices have problems but the way they’re often portrayed doesn’t match my experience.
I agree with the sibling commenter who said that a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.
Re: Maximizing Developer Effectiveness
#150Earlier quoted context omitted.
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.
The corollary being that the technical problem of a microservice architecture is easier to solve than the management problem of leading a single large team. Probably some truth to that.