51–60 of 116 posts
What?
1. Logical positivism is not a proven perspective, it’s actually mostly rejected. How do you falsify “I feel angry”?
2. We aren’t doing science. What’s the hypothesis for “I’m adding a close button”
1) Are you solving the problem that someone (your customer / manager / stakeholder) wants you to solve right now? what makes you think the thing you're working on is the priority, have you checked with someone or got convincing data
2) Are you taking longer than expected? if yes, why? What's a practical solution now and for the future so everyone remains happy? If no, why do you think so?
3) Are the people in charge of your future happy with what you've delivered? How do you know and what's the reason if they're unhappy?
4) If there's a disconnect on any of the points between you and the stakeholders, what is a practical solution that you can implement it quickly?
5) Are you knowledgeable enough that people can rely on you to solve their problems in the most practical manner?
Personally - I don't see a lot of value in this list (I read all 50 items and watched the video and I regret wasting the time). There are certainly some valuable concepts - but the presentation is fairly incoherent (including the video of the talk he gives) and not particularly helpful. Many of these items are utterly unrelated: Some are fairly specific to gaming (profiling/memory layout/timing) some are basic profes…
That gets swept under the rug far too often.
This list makes it clear that communication (of designs, of status, of workarounds, etc) is vital for the professional software engineer.
Personally - I don't see a lot of value in this list (I read all 50 items and watched the video and I regret wasting the time). There are certainly some valuable concepts - but the presentation is fairly incoherent (including the video of the talk he gives) and not particularly helpful. Many of these items are utterly unrelated: Some are fairly specific to gaming (profiling/memory layout/timing) some are basic profes…
> 6. I have a Plan B in case my solution to my current problem doesn’t work.
> 9. I can clearly articulate unknowns and risks associated with my current problem.
These rules imply one of 3 things about the author:
* That author only encounters problems that have been fully solved before
* The manager gives zero weight or value to discovery
* The manager expects the whole project to have been fully specified before starting
Yikes, that's toxic! I think it's important that engineers have the mindset of understanding the problem, but that means that figuring out the problem is part of the work! Which then means that engineers should definitely have periods where they don't understand the problem, where they don't have a Plan B yet, and don't know what the unknowns are, because they can't know what the solution will be until they've started the work.
This guy lost me when I read that I should implement Plan B first.
IMHO it makes sense if Plan B is much simpler, but not as efficient as Plan A (remember, this is a game developer, everything is about efficiency). You build Plan B is a prototype, and could still fall back on it (and iterate on it) if Plan A fails.
If Plan B is more complicated than Plan A, doing it first sounds... dumb.
Having worked in Unity I'd take engineering advice from their top execs with a grain of salt.
This guy in particular has collected some serious credibility. In the past he's worked at Insomniac Games. He is also credited for popularizing Data-Oriented Design and has delivered at least one talk that went viral and that video thumbnail of him in his red flower shirt has become a meme for a no-bullshit and requirement-focused engineering approach. Go check him out on Youtube.
His expectations around producing documentation go only as far as "Think about what documentation or data users need to understand and use your solution." That seems like rather a low bar, compared to items like "I can articulate how all the data I use is laid out in memory." I'd prefer to live in a world where a professional software engineer was expected to write documentation, and expected to be competent at it.
"I can articulate how all the data I use is laid out in memory"
super basic. It's something that you just know by instinct/reflex at any time.