421–430 of 589 posts
Earlier quoted context omitted.
Is the argument that electrical and mechanical engineers are not smarter than the average person? How about figure 8 (PDF page 86) of: https://web.archive.org/web/20120905095856/http://www.ssc.wi...
Doesn't this basically make the argument I'm making, that there's no well-defined band of IQ test scores for different professions?
Earlier quoted context omitted.
I suspect the massive shitshow of Windows 11 and all of its failings is a result of large quantities of vibe code being merged into the OS. People are noticing.
And when exactly did Windows 11 release?
Earlier quoted context omitted.
I suspect the massive shitshow of Windows 11 and all of its failings is a result of large quantities of vibe code being merged into the OS. People are noticing.
Windows 11 was released before vibe coding was viable. And the shit show seems to be that they push ads and bloatware on people, not that it doesn't work reliably. Windows 11 IoT LTSC has been absolutely rock solid for me on both machines I have it on. Waaay more stable and reliable than Linux, and even a bit better than Mac (which is also way better than Linux). If they are vibe coding anything, it hasn't had any ba…
I regularly have major issues with Teams and Outlook. Crashes, not showing messages until hours later, calls dropping every few minutes, and the app just never opening. Just Friday afternoon I could not close Teams from the Task Manager
Coding is easy if you enjoy doing it, met plenty of professional programmers that hated it and never felt the desire to improve. To them it was a way to get a paycheck that paid reasonably well.
Better to have a job you don't like that pays well than to have a job you don't like that pays poorly. But at the same time - if you're smart enough to program well enough to get paid while hating it it's such a shame to not find something you enjoy that will still pay you enough.
I think "Code was never the hardest part" is more fair. Code itself can absolutely be difficult, but it's seldom the most difficult part of a project. Generally the hard part is actually figuring out what you want, and how to achieve what you want, then the actual code is pretty straightforward in most cases. I've been programming since the the 1980s and I'm not insulted by the idea that code isn't the hard part.
Earlier quoted context omitted.
No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software. Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc. The idea that code is mere transcription - which I see a lot in these AI discussions…
> but many details Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete. > Code is a form of low-level design and is where the rubber hits the road. Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to c…
It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.
To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.
Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.
To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.
Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation. Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch dev feedback loop is one of the best methods I know to tackle that.
To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.
Earlier quoted context omitted.
Usually you don't have an option other than leaving, most organisations don't let seniors keep coding and nothing else. Either move up the ladder or leave.
Non-coding architects were typically a by-track rather than superiors to ICs. Though I imagine some of them could think they were. Product managers also often don't have proper reports in the sense line managers would.
No one would jump directly into a Solution Architect.
PMs yeah, those have had various backgrounds how they came there.
Again, on my personal experience.
Earlier quoted context omitted.
Speaking/writing English is easy. Writing literature at the level of Shakespeare is hard. Writing educational content that makes hard concepts accessible like Grant Sanderson is hard. Likewise, coding is easy. It's just writing, and any child can learn it. Coding is not programming, and the hard part of the job lives in that distinction.
English is a hard language to learn, especially as an adult. So many weird rules that everyone takes for granted.
English has simple conjugations. That makes it much easier to learn to speak intelligibly even for adults. Old English dropped many of the complicated word endings because it was used by Anglo-Saxons with Vikings and Normans.
Earlier quoted context omitted.
If what you're saying is true we are moving into an era where rockstar product managers are going to be more in demand than programmers since they can do all of what you mentioned above. And typically (though not always) product managers have better people skills than programmers and consequently they might be more effective at the "gathering requirements" and "working together" bits you mentioned above. Even much of…
A test doesn’t prove much. Highly experienced programmers seem to have a hard time understanding this. Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches? LLMs can be useful tools when guided by experts. I don’t think a PM with a dream is going to cut it in the long run.
Do those tests test the right thing?
Adding more features is given higher priority vs optimizing current features.
Arent humans the weakest link in security, click on some random link and enter your credentials because the fake site looks legit.
>If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers? Because they're not the ones deciding it, they just provide input for the Heads/VPs/managers who make the strategic decisions. And they are paid pretty…
Customer Success definitely doesn't get compensated what they're worth.