111–120 of 120 posts
Earlier quoted context omitted.
Oh, certainly. In a world with far fewer failed software projects, it trivially follows that people would want far less software.
Not sure, what you're saying follows broken windows fallacy. Good software might begat the need for more good and useful software.
I definitely agree that the best teams have cultures that make even normal engineers incredibly effective compared to the status quo. Managers definitely put too much stock in hiring and "engineering quality" compared to culture, trust, systems and processes. > Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. But I have to wonder: if "any a…
because there is, by definition, an extremely limited supply of the "best engineers in the world". if you can afford to pay top-10% salaries, and attract and retain top-10% engineers, more power to you. maybe not literally "any asshole" can do it -- but it certainly asks more of your leaders to craft sociotechnical systems oriented towards learning and enablement. and i don't think that's a bad thing.
Earlier quoted context omitted.
>Writing high-quality code Who defines what "high quality code" is and who enforces it in a team? Because what's high quality to you might not scan to other members of the team, and if you want to your standards across the team then you have to spend time and effort educating the people and enforcing the standards. And now you're wasting time obsessing over standards and guidelines while your efficiency doesn't incre…
> Who defines what "high quality code" is and who enforces it in a team? An engineer who has appreciation for the art of the discipline. But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
That' sounds incredibly vague and useless. The problem is always communicating to management the value add of such a position. If they see money gets made without it, than why bother? The customers don't complain so it's a slam dunk. And most companies are customer focused.
>But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
Like I said, the issue is budgets. Not every company is big-tech and can afford lavish salaries to attract SW shamans to bless your codebase with their appreciation for the craft. Most SW is a commodity, not an art. Some is, sure, but that's cherry-picking.
Earlier quoted context omitted.
Oh, certainly. In a world with far fewer failed software projects, it trivially follows that people would want far less software.
Not sure, what you're saying follows broken windows fallacy. Good software might begat the need for more good and useful software.
Where's the proof for that? And what do you define "good SW"? For the management, "good SW' is whatever makes money fast. It's business.
SW isn't like building chruches or bridges, something to last 100+ years, but something with an incredibly limited lifespan, that will have to be rewritten anyway, so why bother investing too much in "good SW" if "OK SW" will do the same job anyway?
Earlier quoted context omitted.
I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job. Individual ownership at the individual engineer boundary can breed distrust within a team or org, but oft…
I personally think _most_ people should treat their jobs as a _day_ job - unless they have actual ownership in the company (beyond what would be a 50-100k payout at option time)
'Ownership' is taking on those same stresses and responsibilities without any of the potential pay-offs... or at best a marginal rounding error.
It's not surprising that few people want to work as a founder but get compensated like an employee.
Earlier quoted context omitted.
> they eventually lost their appreciation for the artistic side of the discipline It's easy to obsess with the artistic side of the discipline when you're doing it on someone else's money and assume it's coming from an infinite bag. Once you are a manager and given limited resources to get a job done by a certain date, art goes out the window and it's all about efficiency, you get paid to get the job done, not have p…
I said they lost their appreciation , not their obsession . Furthermore, the art of the trade is not "pretty code"; it's a design and implementation that can last decades and not require a rewrite to accommodate new feature demands. There is a balance to be struck between business interests and legitimate engineering concerns around technical debt. And as we've gotten more of these MBA wunderkinds at software compani…
When you're a start-up starting out to build your product, nobody knows what your product or the market will look like in two years, let alone in 10. YTOu might not exist in 2 years if the product isn't a hit, so there' no point in investing in robust codebase if you'll be broke by then.
Very, VERY few companies starting out have the luxury of having secured the funding, customers and the knowledge of knowing upfront what the future will look like in order to plan well from the start.
>Pretty much the entire attitude you espouse in your second paragraph.
It's not my mentality, I'm just telling you what the real world mentality is of those who pony up the cash. Then again, I'm in Europe, where VCs don't throw billions of ZIRP money at SW engineers, so nobody here values your "code quality" but your ability to push something out the door fast and cheap to multiply their investment ASAP.
Earlier quoted context omitted.
Not sure, what you're saying follows broken windows fallacy. Good software might begat the need for more good and useful software.
>Good software might begat the need for more good and useful software. Where's the proof for that? And what do you define "good SW"? For the management, "good SW' is whatever makes money fast. It's business. SW isn't like building chruches or bridges, something to last 100+ years, but something with an incredibly limited lifespan, that will have to be rewritten anyway, so why bother investing too much in "good SW" if…
For that matter, how do you know good software really doesn't last centuries? The practice of software's creation has yet to see its hundredth birthday. We have quite literally not had time to tell, and early results seem suggestive in really either direction.
> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in d…
> I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible
Earlier quoted context omitted.
well obviously there's a ton of variance here. but in the type of engineering i'm most familiar with, any sizable amount of production services or surface layer being owned by a single person is a bad thing. individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.
> individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective. Resilience against what? It isn't like teams make decisions quickly, an individual will get decisions done faster in almost every case, and if they are on leave right now its just slightly slower than a team. For example, if you ask a team "can you get this feature in", likely they will come bac…
> For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later.
feature not a bug etc. they should already have and know their priorities and if yours doesn't trump theirs, there's no reason you should get a concrete answer.
Earlier quoted context omitted.
Not sure, what you're saying follows broken windows fallacy. Good software might begat the need for more good and useful software.
>Good software might begat the need for more good and useful software. Where's the proof for that? And what do you define "good SW"? For the management, "good SW' is whatever makes money fast. It's business. SW isn't like building chruches or bridges, something to last 100+ years, but something with an incredibly limited lifespan, that will have to be rewritten anyway, so why bother investing too much in "good SW" if…
>but something with an incredibly limited lifespan,
Oh hell, I found a js developer with their package du jour. Meanwhile in a lot of enterprise you work with software that is positively ancient.