What makes developers productive?
jeremymikkola.com
jeremymikkola.com
The small team should have a lot of support in terms of an infrastructure platform, strong culture and tooling for development/testing, project management set up for them, an escalation path and check-ins where they can raise blockers. There is a template but essentially the small team is left to work how they want to work.
After the 'chunk' is delivered, there is a week of wrap up, and then a week of maintenance where people are allowed to work on whatever they think is the most pressing issue.
However the technical people needed to work them out with stakeholders can be expensive to have fight with stakeholders for ages, so it tends to be rare. And of course many domains are unknown, so you just keep reiterating until something sticks.
Modern agile sucks, but if you read the old discussions on c2.com of how agile appeared e.g. https://wiki.c2.com/?AgileProcesses there really is a lot of value to find, learn and apply. Of course, the ninjas, blackbelts and cargoculters kill that.
An MS-DOS based program in GWbasic, or Turbo Pascal from the 1980s, or a Visual Basic 6 prototype that someone wrote in the 1990s and still gets the job done, or an excel sheet/google doc that someone does to do the calculations "by hand", are all excellent requirements documents.
They do the work, are executable (so you can test against their behavior), and already account for all the normal error handling, etc. The people who wrote them saved you a few trips over the waterfall, and perhaps a decade of grief and work.
Your closest bet today is to fire up Lazarus anywhere, or VB.NET on a windows box and quickly build the prototype. Once everyone agrees on its behavior, then you're back to the races again. Get buy in on a single quick and dirty prototype, then scale up from there.
No, they are not!
They can be a wonderful resource for the validation tests, but a developer needs a model to start. The documentation of existing tools may be a nice requirement document, provided it is exhaustive enough.
By the way, every time I was requested to implement something "exactly like this gizmo here", I proposed to just keep using that gizmo there, and then the discussion became interesting: "No! We want the same, but...."
As soon as the "but" was pronounced, the person in front of me realised the gravity of the situation: they didn't know what they wanted, and by handing me an ancient (despised) tool they were just planning for me to fail and for them to throw me under the bus.
Managers reading this - if you constantly jump from new features to new features you will ensure that your developers are forced to cut corners, make an unmaintainable mess, increase bugs, development velocity will slow and developers will burn out.
It also causes incentive alignment problems, if I push myself to deliver great quality on-time, and I’m striving and working hard, then I don’t get so much as a “well done” and then an immediate enormous chunk of new work - you’re rewarding hard work and quality with large amounts more work, what’s my incentive to perform? Exhaustion?
Dealing with ambiguous technical problems is scary; there is a real prospect of failure, or going the wrong direction, or hitting an organizational blocker, or failing to anticipate changes... Some would rather work on an assembly line (and force their colleagues to as well) just so someone else can shoulder the responsibility for the hard problems. And their numbers are large enough to influence how software is developed.
So I'm going to say you have seen corporation bastardization of agile and rejected it, which is a good thing.
It's not.
> I have never seen it done correctly
I have. And it wasn't hard. In fact, it seemed entirely effortless at the time.
https://news.ycombinator.com/item?id=36727366
The Agile Industrial Complex is a horror show, but that doesn't mean it's not possible to do agile well.
There absolutely is a way of doing agile well, I've been involved in a number of teams that did. And it worked extremely well. In fact, we did agile way before the agile manifesto came out, and before I was aware of there being a name for the things we were doing. We were just doing them because they make sense, they make us go fast and they let us have fun while doing it. Which is basically what the XP people said when they started writing things down. They never claimed to have invented a brand new way of creating software. No, they were observing that certain teams were very productive, and looked at what those teams were doing. If there was a pattern. Spoiler: there was.
Anyway, I also introduced agile "practices" in a large company. Well, in a small team in a large company. We didn't do a single one of the practices the Agile Industrial Complex proposes and often mandates. The much more important team next to us did. They did all the AIC practices. We did the technical. And interacted closely. Did TDD, worked on trunk, paired when necessary, did stuff alone when not. Did the simplest thing that could possible work. ("Where's your database?" "We'll put it in when we need it". <later> "Oh we're done. I guess we didn't need the database ¯\_(ツ)_/¯" ).
The more important team next to us that was doing Scrum with the standups and whathaveyounot failed. We delivered. Hmm.
And if you can point to the practices being promoted by the AIC as being in direct and obvious conflict with, for example, what's written the Agile Manifesto, and can in fact point to ways of doing it right that are in harmony with the AM and in conflict with the AIC, then it ain't a No True Scotsman fallacy. It's a simple case of the AIC doing it wrong.
In most companies, it seems management is incapable of measuring progress other than “will X be done before Y date”.
Awesome. It is a sight to behold and experience to savour.
> it required the team to be in control of its own destiny
Absolutely. If only someone had written this down. What a missed opportunity!
"The best architectures, requirements, and designs emerge from self-organizing teams."
https://agilemanifesto.org/principles.html
> goal reporting timetable.
"Responding to change over following a plan"
"That's not agile"
Has become one of the most annoying arguments I've ever heard. As someone who experienced a corporate takeover of agile "consultants", I can tell you, it is one of the hardest things to try and deal with people who have their own idea about agile.
"Proper agile" is too "team specific" that maybe it shouldn't have been a "manifesto", just call it good "team practices" and maybe it wouldn't have become such a cult
Now it has been abused to create a whole business with bullshit "agile coaches" who sell agile "bibles" and teach cargo cult.
It joins: - Innovation departments being built the least innovative departments you’ll ever meet - HR departments being the worst at dealing with people
Well, this strongly evidences that these agile coaches are fraudsters who don't know the elementary basics of their specialist field ... ;-)
All of this is to say that I agree with you. 'Agile Methodologies' are a crutch for companies that cannot tolerate agility
I've never seen it done poorly. It's the standard for a reason.
Across my sample size of about 7, half were maybe better than terrible, but only two were good enough where I would say it helped more than it hurt.
The tech industry I think would do well to more rigorously study "Agile" and do some A/B testing. Unfortunately this problem space feels like trying to A/B test forms of government. The downsides are generally known after the fact, are context specific, and there are few good ways to run a control
Yep. Because we currently don't have any way of clearly, concisely and obviously expressing the architecture in the code.
https://2020.programming-conference.org/details/salon-2020-p...
What if we could?
I'm starting to think that if we want to maintain this "race to the bottom" pace, we need a more industrialized/blue collar approach and be more less about the person and more about the tool. Most jobs in my area are web crud controlling a transaction script. there is no problem to solve.
I agree but I also wonder why we would expect them to.
Many coming into the industry have had little formal education in CS or SE. Employers providing substantial training is mostly a thing of the past because retention and professional development for employees has mostly been deprecated in favour of the rapid job-hopping culture. And for a while now it's been such an employee's market that developers haven't needed to invest their own time and money into professional development in order to progress their careers.
So even for relatively senior devs it's easily possible that they could have little academic education, little professional training provided by any of their employers, and little incentive to spend their own time studying. Their understanding might come from nothing but a few years of experience working on only 2 or 3 different products and - if they're lucky - some ideas they've been exposed to through more experienced mentors, team leads and code reviewers.
I personally believe our industry would be infinitely better if we could get back to the idea that professional development is important and employers should both look for people who've been learning and then support their people's ongoing learning themselves. Maybe we can even do that now that the gold rush is over and job-hopping every five minutes for a pay and title bump is no longer the most reliable way to climb the career ladder.
We technically have technical leaders, they used to be engineers eons ago but I don’t think any of them could solve first 3 days of advent of code to save their lives.
It's good to trust your people. You want to foster independence among teams, can do spirit. But most orgs seem totally out of touch with the tech. Too many companies use only business success to discriminate on. And that's just too random, too chaotic to let the work be judged on, to decide how next to operate. There's too much decision making about where to go that needs a deeper level of consideration.
This reminds me of the excellent book 'Shape up' by the team from Basecamp. They also champion upfront 'scoping' to make best use of those six weeks. Highly inspirational book for technically mature organizations.
We also have too many decision makers. We also have too bad and always changing requirements/spec.
Yet we double every year because of pmf and a solid core product.
I think what to work on has also a big impact how productive (measured in $$$ instead of slocs) a team is.
I came into tech for the joy and the wonder. You don't measure joy. You enjoy joy.
It's not that money and output are not important for a business, but obsessing with productivity may cause the opposite effect.
Otherwise we're going to just keep burning more and more people out. And for what?
I don't see anyone in this thread asking for that
even productivity cannot be min-maxed, save for the short term, for the simple reason that we don't know what productivity is. technological revolutions are the prime example of this, where each turn of each revolution shifts the entire idea of what being productive is.
Perhaps if "providing value" is something you have to be conscious of and not something that comes about naturally from doing what energizes you then that's a signal to pursue a different line of work.
Another question, why does a work-place need to provide "ample space to play?" I have trouble knowing what this means. At a hack-a-thon, rather than building some throw-away project that was going to be a space to "play", I opted to see if I could decrease the test run time from its current 25 minutes. Obviously this was not a popular hack-a-thon project, but it was by far the most useful (all the others while cool, were never fully integrated).
I somewhat wonder if the "ample space to play" is reflective of an attitude where engineers need to be managed, and like children they need some recess time to burn off excess energy and to be made happy. Is that your take at all? What benefits does this "ample play" provide, and what does that look like? A very important element of job satisfaction is to not have your work thrown away. A "play" project seems exactly something like that. Given this, my impression of providing space to play means: (1) the developers are not taken seriously, are things to be managed, and are not partners in identifying user and business needs, nor are they drivers of identifying business process value [eg: hey, we could automate this, we could optimize that, what if we tweaked this thing a little bit and could then solve a few user-needs at once; vs just building what you are told exactly how you are told]. (2) the 'space to play' is going to be demotivating. "hey, the regular stuff is soul sucking, so here is some time to do something that is not soul-sucking, but it's 'play' and whatever you choose to work on is just a toy and like a toy we'll throw it away.
So, I'm really curious what this "play time" or "play space" looks like. If a developer chooses to work on something, either they are picking projects that do nothing, or they are picking projects that arguably should be already integral to the business development process (and hence should not be 'play' projects at all). Overall, it is work, and if you tell someone that has spent 3 days debugging J2EE configs or YAML configs that they should not expect 100% joy and wonder, or spending a week trying to fathom what the previous time rushed (time-boxes & project focused) developers jammed into the system, & you'll probably getter a rather curt 2 word response rhyming with 'no pit'. That is to say, it is work, I don't think the development profession expects for there to be "space to play", and if so, why are we bothering with wasting time like that? (which seems to be a good way to boost productivity, cut out this throw-away play-time. If developers want to play, as in boost productivity by developing their personal skills, that is for off-the-clock [find an OSS project]).
Sorry the rant-like nature. In sum, I do have these questions: (1) Why is work-life balance pertinent to productivity at work, as related to development process? Asked another way, how does a work-life balance interact with any "Agile" development process such that the efficacy of that agile process is changed by 'work-life' balance? (2) What is "ample space to play" - what does that look like? What artifacts come out of that? If useful things are being built, then why isn't that just part of the work? If useful things are not being built and are being thrown away, how does that help anything?
And this very site is built by that VC.
I'm still trying to figure out how to better regulate myself away from those extremes (how to put my work down for the sake of other aspects of my life when I'm excited on the one hand, and how to push through and 'reset' when I am frustrated by something outside my control on the other). But one of the things I've already learned is that focusing on productivity in terms of sheer discipline doesn't really work. I get a lot farther working with self-reflection on my emotions and carving out space for joy and freedom in the formal structure of my work week than with sheer mental effort.
On the other hand, most days I'm just too mentally exhausted to work on programming when I get home. So I rarely get to scratch that itch on my own time.
To get around that, every now and then I take some time while working on some issue to do something new, like play around with programming language constructs and exploring the limits of the language.
It's not always easy to do though, with deadlines and whatnot. So can be a real struggle at times.
Any trillion dollar capital outlay will invariably measure performance, irrespective of the motivations of sector's people.
Yes. And that is a Bad Thing. That kills joy and wonder.
All the other things the engineers can themselves address (e.g. better tooling, etc), but the organization’s culture around protecting makers schedule is impossible to address individually
Everyone choosing their own tools? Isn't there usually some central department that takes care about that, at best controlled by a kind of committee representing those who use the tools, typically full of people who are no longer doing practical work and have no idea what improvements have been made outside of the company during the last decades?
Sometimes people change tools for the wrong reason. I've been in many companies that changed their bug tracker because the old one was too cumbersome, but they never addressed why all those mandatory fields were added to the old one, and so in a few years they learn the hard way and now the new one is cumbersome because of all the mandatory fields.
IMO the thing that really matters is domain knowledge, a fancy way of saying judgement. If you know your domain you might avoid the most expensive mistakes: having to change language or framework, requiring entirely different developers, bricking hardware that you paid a lot of money for, buying services that you don't need, writing code that won't be used.
Another thing I'd mention is having people to bounce ideas off. LLMs are actually ok at this, in the sense of spitting out lists of things that you might have missed. But in general having another expert around to really discuss stuff saves a lot of time going down caves that you forgot not to go down.
Listen, I'm an infra guy, so maybe this hit a nerve, but 'othering' infra because it's inconvenient has got to stop. Infra serves many masters and you are probably the most flexible of them -- that's why there's so much push back.
For the record, I'm an infrastructure person.
This is an incredibly demeaning comment. Assuming your colleagues have inherent worth and that they're doing their jobs reasonably given the constraints and demands placed upon them is a far more humane way to go about work.
> The business cares about time to market, not the perfect little homegrown PaaS the infra team built.
Those "perfect little homegrown PaaS" solutions get built for a reason - because of what happens after you get to market: the business starts to care a whole lot about how much it costs to run the thing you just shipped.
One of the main reasons a "perfect little homegrown PaaS" gets built is because it's typically a lot cheaper to run in-house. Lots of downsides to it, for sure, but you can't neglect the immense cost of a PaaS when you're running a business.
That sounds cute, but humans don't have inherent worth in a business. If you don't contribute to success (and aren't good enough at deceiving people that you are), you're going to get laid off.
I think that's what the parent comment is saying - infra is competing with potentially cheaper and more flexible solutions. Even if they do their jobs the best they can, put 100% effort in, yada yada yada - if there's a more efficient solution, infra as a whole will be left behind.
For example? The managed or cloud or... solutions are normally magnitudes more expensive than in house. PaaS are the closest in cost, due to the admin savings etc. but even there, we know current prices are investor funded to gain share.
At the far end, compare what you can get for $150/month at Hetzner vs. AWS. At real scale, paying for an infra team to run it will save a lot of money (and I've yet to see a fully managed solution which doesn't have a team of YAMLers anyway.)
> even there, we know current prices are investor funded to gain share
Of course humans have inherent worth in a business - humans are the business. I refuse to emulate the hyper-capitalist mindset of "some people are worthless." I'm not sure if you're saying that this is a value you hold, but it is certainly a value I do not share. There's a lot of room to talk about what "value" is in a business (including how some "value" is more readily quantified than others, and how we tend to mistake that for the only "value" that exists). But we have to stop conflating that with the worth of the humans in the business - that's not a humane way to view your fellow man.
> infra is competing with potentially cheaper and more flexible solutions
[citation needed]
I've been in the field for awhile now, and I can't say I've ever seen a PaaS turn out to be more flexible or cheaper in the long run. Even my beloved Heroku, to whom I compare all present and past PaaS offerings on the market! There are some limited exceptions I recognize for things like internal applications, or niche applications that do not have a broad user base (and never will), but I don't think those exceptions are enough to support the statement.
Our industry chases fads in a circle. This isn't the first time we've all decried "infra is bad, long live hosted services!" - Heroku's heydey wasn't that long ago, and I fondly recall App Engine being a big deal. Then the bill comes due and people migrate. Hell, you could even consider mainframes a part of the cycle, if you squint at it.
OK, can you please send me paychecks for doing nothing in your company? I have inherent value in your business, afterall. Thanks.
I then realized later that leadership and getting a large group of humans to work on a common goal is very difficult.
The idea the other group is doing nothing is usually a perception (or a lack of perspective, lack of empathy, and maybe arrogance), usually.
I know, I know - "time to market", "scaling on demand", "open source isn't free", "not our core competency", etc.
Infra staffing, hardware, scaling, and upgrades are expensive. But it doesn't help the fact that cloud costs an arm and a leg too.
I can't believe we haven't seen more of a race to the bottom in terms of costs and offerings.
Amazon is gorging itself on your margin. I wish we lived in a world with 20 AWSes, all at the same scale and market penetration.
We run an 8 figure business on mid 5 figure managed infra costs. An infrastructure team would be several multiples more expensive than that... even if it was a single individual.
Just because you can do it yourself or more cheaply, doesn't mean the effective business costs are less.
Edited: for grammar
Clearly, because "DevOps" people / skills are for free right?
Good software engineers who additionally have exp with Cloud and all its craziness definitely aren't asking for way higher salaries?
I've worked in small size data center and the amount of work performed by 2x minimal wage technicians was huge.
They were running on 5-10 engineers + 3 more skilled ppl at day and 1 person on night shift with 1 or 2 being "wakeable"
"Is a product made by grown ups familiar with your sector" is an actual selling point for most enterprise SaaS.
It's become a classic problem. Organisations want to centralise infrastructure and services because consolidation saves on costs and increases visibility and control. Particularly if you're under specific regulations that can make things much easier.
But that only happens if the centralised provision actually works. It has to be adequately resourced and reasonably well managed and supportive of the people using the infrastructure or services it provides.
If the centralised provision is not good then it had one job and failed to do it. Whose fault it is doesn't really matter. It's not supporting the other parts of the organisation to do their jobs and inevitably a point will come where that infra gets "othered".
We've been seeing this phenomenon ever since we had central system administrators who could lock down the OS on individual employees' workstations. The admins argue that they need to make sure security updates are properly deployed and they need to prevent non-expert users from breaking things and they need to ensure consistency because they're also running the help desk and ultimately they're responsible for these things so they need the authority to control them. All very fair and reasonable. And all completely irrelevant to someone with actual revenue-generating work to do who is being blocked for days or weeks because some sysadmin whose opinions are not necessarily justified by their effectiveness hasn't enabled or authorised some essential facility.
Both infrastructure and applications will follow the same workflow - all changes via pull/merge requests, Jira integration, etc.
Developers won't have the ability to create resources outside of the CI platform.
It's not like we flicked a switch overnight - that would be insane - it's a large scale cloud migration project over many years.
Unfortunately I've also been involved in the emergency bandage fix once it was discovered...
They know what the actual details required for the inputs and outputs are, along with all the means to do the computations. Once they give you something that works (no matter how slow or kludgy), you have an executable specification to refactor, or rewrite, and you can A/B test to make sure your code works correctly compared to their reference/spec.
You spend some valuable time on the part of the experts, but you more than make up for it in saved time doing the wrong thing across possibly years.
Devs are gatekeeping way too much. More no-code/low-code is the way forward. It's always just a balance of how much abstraction to add.
No-code/low-code tools are great for prototypes, but are awful for software that is large enough. for small businesses many will not get to that point because many businesses sink by that time, but absolutely unusable for many enterprise software. Those solutions slow down devs past a certain level of complexity (and that level isn't all that high) but no-code/low-code experts will either not know any better or won't tell you. I have legitimately tried using a few, but they become a pain to work it beyond the initial prototype. I put them in the similar territory as Wordpress because they remind me of the pain of maintaining them.
Non-devs always underestimate complexity of software at scale. Even devs do as well. It's not gatekeeping otherwise, devs would already be out of a job
In my case, having ADHD and going undiagnosed for decades (I only got diagnosed last December) has caused me to blame myself and my conscious actions for things directly caused by the neurochemistry of my brain. This year may have been my most productive ever.
Why?
I was feeling good about what I was doing and I just kept going. I was on a roll.
Many of the changes that were on my list to do that day weren’t directly related but I was in a good mood. Things are working so I did a bunch more.
When you get that good feeling it makes a huge difference in the outcome.
If I had felt bad or overwhelmed, I probably wouldn’t of been nearly as ambitious.
Having a bunch of go-to guidelines is nice but really, you all just have to be on the same page whats the current state and to be able to say honestly whats going wrong when it happens.
Treating developers as monkeys who'll do as dictated doesnt really sit well for many of them.
my focus is lost and I start thinking about lunch
Knowing what to build, Doing fewer things, Tooling that reacts quickly, Knowledge in the developer’s head, etc.
The whole article only mentions topics that developers can fix themselves, not stuff that we cannot change and are very important in the daily work.
it's incredibly discomforting to spend even 10 minutes building things the other party clearly doesn't want, but since everyone is a bloody "head" or "chief" of something, no one ever clearly defined upstream-downstream relations between teams. There is a lot of infighting and parleying over everything.
for the same reason, we switch gears mostly every 90 days, and most of the code has been written by some very junior programmers that never deleted any now unused feature and spaghettized everything (every 1-n relation has the fk on the wrong side lol). the PO is also a nice guy but absolutely incompetent at navigating this particular org, as suffers from the hero syndrome and wants to save the company.
the pay is decent (for where I live at least; it's a /10 from the "500k tc/1 yoy" reality of usa, and i have like 10 YoY, even if I worked in very modest places so not many big challenges), and i'm changing house in a couple of months. Thanks to idiotic local policies the furniture+building materials prices skyrocketed (literally 2-5x). This is literally the last bit of motivation I have and I'm counting the days until I can finally let go of those cretins, even if I have to stay a couple months without work.
If my productivity will eventually turn into profit that I can get by some bonus or rewards sharing, I will figure out so many ways to boost my productivity instead of waiting for a group of MBAs to figure out how to do the optimal KPI on me.
HR: What's your dream about your job here?
Me: My dream is to earn enough so I do not need work here(by the way, most likely that means the company will also be successful)
but that raises an interesting question: how to find startups that have best chance to make it to join and help to make that happen?
There are some people that are clearly into S&M, that proudly bring their kinks into project design.
This is extremely funny, because we all know this is actually true =)
In my experience, simple solutions are not the lazy minimal-effort ones. It takes a lot of work to distill complex problems down into simple solutions.
Mark Twain was just an alias the author thought sounded engaging... and quoting an alias is like quoting Batman.
Incredibly funny, but hardly meaningful... =)
If I feel like there's a small chance of my commit being accepted, or ever mattering, it's hard to fake the motivation to work on it.
When I've seen this happen it usually boils down to communication problems. The solution is often to talk to the reviewers _before_ writing the PR.
For example,
1. Disagreement about the problem/solution - hash out the design first, then write the code
2. Disagreement about priorities - align expectations before investing too much time in design or code
3. (etc)
Yes, communication is hard. Unfortunately, it's really the only way to get things done with other people. Building decent communication skills is a worthwhile investment for all SWEs
If you're feeling particularly bold, you can hold two of these jobs and do something unheard of in recent times: actually being able to save for a decent retirement.
This may be true when looking at a single individual, but this is exactly how teams get locked into the bus factor of 1. The person who creates a codebase needs to train others on their knowledge, so the entire team has that understanding that allows them to be productive. The slowdown to train someone up to know as much as the creator is quickly paid off when 2 people know the codebase. And it scales more with each new person because not only do more people know it, but the knowledge transfer gets streamlined and the confusing parts of the app are identified and fixed.
Not to say every person should have a silo-ed portion of the codebase that nobody else ever touches or understands. I just think the pendulum has swung too far in the other direction.
Yes. It's one of those mythical management "best practices" that never actually happens because it doesn't work.
Most interesting software development involves creative thinking. Unless someone finds a way to download the entire thought process of the original developers and losslessly transfer it to other developers later you can't recreate 100% of the knowledge and insights that came from the original development work.
What you can do is acknowledge that your developers are individuals with unique knowledge and abilities not just in general but because of their history within your own organisation. Value the unique experience they collect while working with you and - for as long as they remain with the organisation - encourage them to actively support colleagues who are later working in the same part of the code.
There is no substitute for retaining that knowledge and having the original source directly accessible but of course most people do move on eventually. So it's also a good idea to emphasise good design and coding and documentation practices so that even when the original developers move on and you'll never have access to the ideal source of knowledge again you still have enough to figure things out when you need to. The fallacy is the idea that working that way will ever be comparable in productivity to having the original source still around and willing to help.
I’ve been on several teams that consistently endeavor to keep the knowledge of a code base shared, but every time the code base reaches a certain size, the Bus Factor creeps right back in, but this time for “modules” or areas of the broader code base.
Combine a large code base, 4-8 engineers making constant changes all over, and it becomes a real struggle to keep everyone “up” on the whole thing.
Has anyone seen a workable strategy for this?
Encouraging the mindset to be able/willing to learn new areas as needed: teaching a man to fish.
And the definition of fun can be elastic, but.. it has to be there.
For me, it's zero friction from problem solving to actual running code.
Every single stage of this can be a flaky system, adding unnecessary toil on engineers. And your reports are not paid to fix all the toil.
Management should figure this out and bring it up to relevant teams to solve these issues before asking engineers to "do it faster"
> Tooling that reacts quickly.
> Helpful infrastructure
Android developers would find this list depressing: huge SDK that never stabilises, Android Studio is the new Crysys, Gradle (and its scala dsl) is just confusing.
I want I code, so just let me focus on that.
We used to say that the process will never turn a mediocre engineer into a good one but it will absolutely turn a good engineer into a mediocre one.
In general, I've observed that a lot of these heavyweight processes are used as a substitute for high quality engineering leadership. They are not a good substitute.
This shifts the problem into defining and growing engineering leadership (which was my original quest too)