111–120 of 165 posts
While it is optimal to minimise transactional cost due to context switching in that case, maintaining a constant throughput in that scenario would be sub optimal.
Superb write up, though!
Earlier quoted context omitted.
I think for junior developers that might be true. Does the name connect? :)
I've worked with (and been a) staff engineers who have fallen into the same trap. Over engineering is something that we need to constantly be cognizant of because it's often dependant on scope. E.g. are microservices over engineering? If you have 1 user now, and only expect 100 total users over the next 2 years, probably. If you're running AWS, definitely not. Everything in between becomes a grey area that requires t…
Earlier quoted context omitted.
It is also a rookie mistake to think that just because some tasks might blow up, you can't accurately estimate a large class of them to within a reasonable confidence window (say, within one day 99% of the time), and likewise identify those tasks with a large chance of blowing up. Breaking down tasks into smaller tasks seems to help build this skill faster in some people. If you don't want to be a mindless drone, you…
It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity budget prior to development without knowing the upper bound of your problem's complexity. Some things still have to be discovered before they can be measured.
Earlier quoted context omitted.
You get a pretty good ratio by doing very little using only that metric.
I think the purpose of this ratio is that a predictable low is better than an unpredictable high. It's sort of the same idea as padding out an ECD. Better to sometimes impress than sometimes disappoint.
Earlier quoted context omitted.
I've worked with (and been a) staff engineers who have fallen into the same trap. Over engineering is something that we need to constantly be cognizant of because it's often dependant on scope. E.g. are microservices over engineering? If you have 1 user now, and only expect 100 total users over the next 2 years, probably. If you're running AWS, definitely not. Everything in between becomes a grey area that requires t…
Well, sure. I wasn't saying it never happens to non-junior engineers.
> I think for junior developers that might be true.
That strongly implies, if not outright says, "this only inflicts junior engineers".
Earlier quoted context omitted.
It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity budget prior to development without knowing the upper bound of your problem's complexity. Some things still have to be discovered before they can be measured.
But it doesn’t need to be possible all the time, just often enough to set bounds acceptable to the rest of the organization. And how are you going to know unless you’ve already done it a hundred times, and/or try?
Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time.
Predicting the future of a high entropy system is predicted to always be hard if you're aiming for 99% accuracy. Solving for hard problems AND solving for this particularly hard problem on a daily basis is less energy efficient than if you stop trying to predict the future at every standup and trust that your average best guess while ignoring the future is good enough to keep you going until the end of this task.
TL;DR: Spend less energy sampling the efficiency of human creativity and spend more (but still not too much) on removing barriers that limit creativity.
Earlier quoted context omitted.
What kind of micromanagement did you experience / E.g. do you have an example? I'm in the position where I as tech lead don't fully know if I can trust my team (yet) to do the right decisions. One of the reason is that our product is quite new, and we haven't discussed developing principles yet. And some people tend to over engineer stuff all the time. But I also don't want to micromanage.
Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do seem like to have this kind of daily routine so your mileage may vary obviously. Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I…
Agreed, and some teams go even further than that. I have to update statuses multiple times a day. If I don't, I get nagged about the status of this or that (as though I can do more than one thing at a time). I wish I could just say "I am doing A because I am waiting on B just like I was yesterday" and have it stick.
Earlier quoted context omitted.
I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.
I believe this also depends on who you ask For me deadlines are simply "someone wants this and this delivered @" I work on it a couple of days and then I tell that someone if it's reasonable and if it's not reasonable, what they are gonna get instead. Most of the times deadlines are way off the mark and it also happens that they take 1/3 of the planned time, in that case instead of over engineering, I simply rest or…
Earlier quoted context omitted.
Can you prove that their "overengineering" makes things worse? And not just in the short term, but also for maintainability down the road, accounting for their developer experience and job satisfaction, etc? Otherwise maybe it's just a healthy level of engineering, knowing the details that person knows. The management advice I was given is that if you don't first trust people, they will never get a chance to show you…
Of course you can't prove that these four extra layers of abstraction will never be useful, but they aren't right now. That's why people with over 10 years in the industry are valuable - they have the intuition to see this coming. The dev took twice as long to build the feature as they needed to, and updates to the code also take twice as long. I have seen this over and over, and GP is correct - there are some engine…
Earlier quoted context omitted.
Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do seem like to have this kind of daily routine so your mileage may vary obviously. Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I…
> Having to report every day during the daily stand up felt like micromanagement to me. Agreed, and some teams go even further than that. I have to update statuses multiple times a day. If I don't, I get nagged about the status of this or that (as though I can do more than one thing at a time). I wish I could just say "I am doing A because I am waiting on B just like I was yesterday" and have it stick.
Standups daily, then we’d have weekly all hands that I had to prepare status updates for, then a weekly 1:1 with my boss that needed status updates, and then each week my team would have to type out what we accomplished at the end of the week so the Director could send it to the execs for the weekly reviews.
The result? I am giving the same status updates to the same people upwards of four to five times in a single week. There were moments when I legitimately wanted to ask my boss in a very flippant way about his note taking abilities but that wouldn’t have done much but get me in the management dog house probably.
It was a source of annoyance with every other dev I talked to about it.