> I can articulate precisely what problem I am trying to solve.
It's appropriate to put this one first because it shows up in so many of the problems that follow.
Easier said than done when there's a deadline pistol pointing at your head. You gotta get stuff done. Show progress. Writing any kind of specification is just a slippery slope to Waterfall, geez. There's no time of any of that namby-pamby talking to and watching users BS. They don't know what they want anyway! Real developers ship!!
Excess time pressure is behind so many problems. It's the thing I'm always most concerned to manage when I start a new gig. That said, shipping early and often is one of the best ways to mitigate excess time pressure, because it helps build trust between stakeholders and the team. The longer the release cycle, the more likely it is that business stakeholders will get antsy and start doing harmful things.
"I can articulate precisely what problem I'm trying to solve" is not just on that person. It is a function of their collaborators – product/program/engineering managers and other engineers around them.
If you are in a culture where it is acceptable to send tasks at each other without much context, and with harsh deadlines, and with a perf management system that rewards execution under such conditions, then you will get precisely the opposite of someone who can articulate what problem they are trying to solve.
In fact you will get a culture where asking questions for deeper 'why' understanding will be seen as disruptive.
> I can articulate why my problem is important to solve.
At this point in the list we start to diverge from what engineers/developers are allowed to know in the modern enterprise. Here is where we start to get push back from the Program/Product managers, Scrum Masters et al. To proceed further down the list is to remove the added communication channels between engineering and the business.
At the end of the day, the people signing paychecks care more about their priorities than they do about these 50 points. But they can be useful to keep in the back of your mind when making decisions that aren't governed by anyone else.
Which, if any of the list of 50 do you think is unreasonable? I don't always explicitly do all of these things all the time on every project, but I'm certainly _capable_ of doing so. For example, working in backend web dev, I generally don't go into it thinking explicitly about, say, memory usage, as long as my monitoring tools are not telling me there's a problem. Of course, there are exceptions, which is why I said "generally" (for instance, if I know I'm making a query to the DB that's going to yield 100k results, I'll definitely be thinking about memory usage), but I also don't just YOLO it and see if things crash.
None of them. But all of them combined. And they never are all part of the same job description; except perhaps in an organization small enough to not have job descriptions.
I disagree. I think the list of 50 is an entirely reasonable set of expectations for a senior (or at least staff+ level) engineer, with the caveat in my previous comment that not all of these things need to be done explicitly, every time, on every project. Like another commenter said, being able to articulate something isn't the same as explicitly doing it.
I also realized, I'd put a small asterisk on "I have recently profiled the performance of my system," as well. I would expect that an engineer would do at least some minimal profiling of their code in order to make sure it's not too slow in itself and doesn't excessively slow down any calling code, but for the most part, with a running production system, it's generally safe to assume that performance is good enough unless you've been shown or told otherwise. And I think that all still fits into the spirt of the expectation as well.
You only implement the Plan B if Plan A fails. Plan B doesn’t have to be elaborate. It can be as simple as, “I’m going to look into using this third-party service to solve 99% of this problem, but if it isn’t a good fit or it’s too expensive, I think we can put together a home-grown 80% solution in a couple of sprints.”
Well one case where it can make a lot of sense is when Plan B is a quadratic/exponential solution that can be written in one day but there are complex to write/research item solutions that are much faster for Plan A.
Expecting an engineer to do all of this even when they are at odds with rest of the execution machinery is simply not practical. It leads to heroic behaviours and burnout.
I hope this guy has a complimentary list of 50 things for other roles.
I mean yeah this is great on paper, and applicable for bigger projects, but for day to day stuff there is no way I’m gonna pull another engineer in to run through these steps.
This kinda stuff always reminds me of someone making a PR for something like a react component that lets you choose a time zone. It can be a 100 line simple thing or it can be an 800 line monster with files for typescript types thorough tests, etc. I prefer the former but I feel the author would expect the latter.
I really love these points as a North Star, but these would be mostly aspirational for teams I've been on.
I work on a team now where we get huge scopes of work and a couple people will tear that work down and would answer these questions as they do so. However, most teams I've been on deal with far more interrupts than the team I'm on now does. Those interrupts are lemented but justified by the business and definitely impact an engineers dedication to a given projects. Interrupt driven work is a sort of split brain problem that I think gets in the way of answering these kinds of questions because it removes the time that an engineer would otherwise spend entrenching themselves enough to know the answers and problemscape.
It sounds like you don't think these expectations are unreasonable in a healthy environment. Is that what you're getting at? I believe it's possible to hit 50/50, and I think I personally do (with the caveat that I don't do all of these things explicitly, every time, on every project), BUT I'm also on a high performing team in a healthy work environment.
I think the expectations are fine. In a sense I actually judge the engineer less than Mike does according to these criteria. If you can answer these questions I think it says more about how your team organizes and accounts for work more than the diligence and knowledge of a single engineer.
> with the caveat that I don't do all of these things explicitly, every time, on every project
which is totally fine, most of those things don't need to be done explicitly. (as such they take less time than many commenters seem to think they would.)
being able to articulate something doesn't mean that you've taken the time to do so. just that you've generally thought about your task enough before starting it that if your boss asks you that question, you can produce a coherent answer in a timely fashion.
This is a great resource, thank you! Gives me a lot of actionable concrete issues to work on. Maybe I'm just very early in my career or it has to with the subfield I am in (bioinformatics, machine learning) but I should have been fired 20 times over by these standards.
The reality is that in a healthy workplace, you could whiff on 25-30 of these and not get fired, because a healthy workplace gives employees guidance and room to grow. Eventually with enough time in that place you'd be at 40+. Of course, some of them (like professionalism) are basically non-negotiable. But nobody starts at 100%.
Let's be honest here, a green junior or intern could easily whiff on 45+ of these things and not get fired, as long as they're in a healthy workplace and they have a growth mindset. I literally tell interns at my company that I basically expect them to know fuck all, and that their opportunities at the company are mostly limited by their work ethic, their willingness to ask questions, and their desire to accept and incorporate feedback.
On one hand, well yes, everything mostly makes sense.
On the other, I can easily imagine the reaction from most project managers if they'd asked me put together an estimate for fully achieving all of these on any given project. Some of them would involve sitting in on business strategy meetings, which is a pretty far cry from the level of involvement I generally get! It's sometimes hard to even get hold of representative hardware to test on.
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 professional expectations (I can schedule my time well). In neither case is there real advice for people who actually struggle with some of these areas.
My item number 51 would be... "I can articulate my point in a more compelling manner than an incoherent collection of 50 things I don't like"
I think it has a so what problem. It sounds nice but then so...? I failed to understand what exactly the author wanted to convince people to do. Expectations - for who? Let's say someone does exactly this, then failed to actually ship something that people want then it's as useless as not knowing the list at all.
> I failed to understand what exactly the author wanted to convince people to do.
He’s writing a list as part of his imaginary shower argument with his boss and coworkers as to why they are all inferior and he’s perfect and why all the problems they are facing are easily attributed to his list of 50 points of things he feels he does that they are failing to live up to.
Not just that, but also "am I in the habit of doing things that are conducive to situational awareness" which is perhaps the even more important bit! You can have all the situational awareness in the world now, but when it really matters is when the context changes.
No disagreement, but I'd suggest that situational awareness is an ongoing thing, so if you don't notice when context changes, you never really had situational awareness.
One funny thing about situational awareness is that when you lose it, you don't always know, because, well, you've lost your SA.
Put differently, something you consistently find when you postmortem incidents where people have lost their SA is that they thought at the time they had full SA. They only notice they've lost it when things are clearly going downhill.
So it's important to regularly re-ground yourself with reality even if you think you don't need it. That's a critical component of maintaining SA.
Does it? Almost every day we get articles on every existing medium regarding the importance of communication. Even the tech circles in 4chan parrot it. Yes, the place known for anti-social recluses parrots it, too.
And it's showing. There is so much emphasis on communication, people started equating quantity to quality. "Just talk more, that's what great communication is about" wouldn't be an observation too far from the truth.
Far too little is invested into researching what makes quality communication. It's just the same old rational arguments against rational arguments, day in, day out. For a field entirely about managing and sharing information, be it to machines or to people, that's pathetic.
If you only compare the sermon to the hymns, it does seem a little redundant. But if I look around my workplace, clear, frequent communication is absolutely a huge need.
Again, this is purely anecdotal and at best rational only. Our field is already loaded with rationality, and most of our "this is clearly better" cases fail to reveal any improvements in case studies.
If people are so certain it is better and believe it is important, let them stake money on it and do research. Until then, the cat is both dead and alive.
I found some value in this list (read it, but didn't watch) but I agree that 50 unorganized bullet points is too much. I think they could break it down into 6 or 7 larger themes: communication, being a good citizen, using a systematic development process, investing in developer tools, understanding real world end-user requirements, technical requirements, and data flows. All good advice, maybe not the best delivery.
I find it ironic that the lists focused so much in communication, and yet it had me confused and lost (ie: It failed to communicate to me what this list is about).
I view these less as actionable items, and more as character hallmarks. No you don't need to actively be making sure you're doing All The Things by iterating through this every day. Yes these are things that should be captured by your company's best practices, and your own professional integrity.
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.
That's not a high bar, it's an arbitrary hoop. It'd be like saying "I always know which processor cache my variables are sitting in". In modern languages it may be literally impossible to look at a block of code and know what's sitting in the heap vs. on the stack, and the heap is often broken into many different components only fully understood by the compiler/interpreter/VM writers. We want to abdicate responsibility of this kind of memory management to the interpreter, just like we want to abdicate responsibility for handling processor cache levels. If you can articulate how all the data you use is laid out in memory all the time, you are majorly micro-managing the runtime.
Not sure if you're familiar with Mike Acton (as mentioned in the article). One of his key points of focus is data-oriented design, and that when designing software, ignoring the architectural realities of the hardware is ignoring one of your responsibilities as an engineer to deliver performant software.
Now, it's possible to argue that writing performant software is not important. The prevailing modern sentiment definitely seems to be "The compiler / interpreter takes care of that". But given his track record of delivering high performant running software, and the trend in computing towards sluggishness, I'm trending more and more towards his camp, than the "don't micro-manage the runtime" camp (which is starting to feel more and more like a thinly-veiled "I don't want to have to think about it").
I don't think it's thinly veiled at all. Some people might be deluding themselves into thinking they aren't losing something by abstracting away the intricacies of the runtime but I imagine most are actively thinking they are okay with this tradeoff. Instead they are allowed to focus more on the domain problems and let their users tell them when it gets to be too slow. Whether it's the right trade off probably depends on what their goals are.
> Now, it's possible to argue that writing performant software is not important.
The quote I'm arguing against is "I can articulate how all the data I use is laid out in memory." Indeed, writing performant code is not important, most of the time. It is critically important a small amount of the time (actual percentages heavily dependent on the type of software), and yes, in those times, understanding the architectural realities of the hardware is somewhere on the list of things you need to understand to do so, just below a solid understanding of complexity analysis, a wide knowledge of useful data structures, proper design of queries and use of indexes (if relevant), etc. A good software engineer does not say "I always know exactly how all my data is laid out in memory", they say "I know when and how to care about that, and the rest of the times I ignore it." Just like they do with many, many other concerns. Anything else is just premature optimization. The most important problem solving skill by far is knowing what you can safely ignore.
You want to (I do too!) , but the abstraction eventually leaks (you get unexpected behavior in long running processes because of gc/libc/kernel issues, or you need very specific control performance wise, etc) , and you end up having to know about it.
> We want to abdicate responsibility of this kind of memory management to the interpreter, just like we want to abdicate responsibility for handling processor cache levels. If you can articulate how all the data you use is laid out in memory all the time, you are majorly micro-managing the runtime.
Unfortunately, in practice, it's not possible to be oblivious of the layout of data in memory if we want to write fast code. The CPU/memory speed disparity graph [1] shows the new reality for programmers: the slowest part of a program is bringing data from RAM into the CPU registers. Fortunately, modern CPUs have very fast caches that help amortize this cost and it's the responsibility of the programmer to organize data to take advantage of that fast hardware—the compiler cannot do it. That's why two functions, with the same algorithmic complexity, and which compute the same result, can have an order of magnitude of difference in performance between them [2]. The famed sufficiently smart compiler that can do those transformations does not yet exist as far as I know.
If the slowest part of your program is waiting for RAM to get into your CPU registers, then you have one of the most blazingly fast programs ever written. Grats! The vast majority of software has much, much, much lower-hanging fruit than that: things like O(n^2) algorithms where O(n) exists, SELECT N+1 issues, missing database indexes, missing easy wins with caching, repeated work, threads blocking each other, loading more data than necessary, throwing and then suppressing exceptions everywhere, bad netcode, doing work serially that could be paralyzed, etc. In this software, fixing these issues will be 10x easier and result in 10x larger speedups than worrying about organizing your data to get loaded from RAM into CPU caches more quickly. That makes this advice counterproductive for most programmers to hear.
Knowing how your data is structured in memory is a trivial exercise for anyone working on a game engine like the author of this talk. You don't even need to think about it. The layout of every data structure used by the engine is known and chances are you have implemented a bunch of them yourself.
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.
You wrote: <<This guy in particular has collected some serious credibility.>>
I'm confused. The blog post is written by Adam Johnson. Are you referring to Mike Acton or Adam Johnson?
I never heard of Adam Johnson before this HN post. From his books, he appears to be an expert in Django. Yes, I agree about Mike Acton and his ideas around Data-Oriented Design. It sounds like a very interesting approach to programming in a resource constrained environment.
I'm referring to Mike Acton (as you already figured out). As I understand it, the author is only summing up a talk by Acton to written form.
> It sounds like a very interesting approach to programming in a resource constrained environment.
It's more of an approach that is maintainable and straightforward, and only coincidentally (well, not really...) also straightforward and fast to execute.
If you are truly working on something innovative, chances are that Plan B is already up and running. It is your competitor's solution that you are trying to replace with a better one.
For example, my new data management system can also do many traditional relational database table operations. If you want to do fast analytics or queries, then it can do it better than the competition. For basic stuff, other RDBMS solutions will surely get the job done; but if you want to build a pivot table against values in a 10M row relational table then this is the tool you want: https://www.youtube.com/watch?v=2ScBd-71OLQ
> Say it’s Wednesday, you have a project due on Friday, and you get some new task dropped on your lap. You think “I’ll do the new thing now, and make up the time for the original task by Friday”… mistake! Communicate about the conflict on Wednesday. Your product manager will help manage the timing and risk.
My product manager was fired a while ago and no one has replaced him formally yet. A C-level guy is micromanaging my team's work now and he sucks at it. I really miss being able to push back on these conflicts.
Assuming (yeah, I know...) new task is 'critical, it's usually enough to go 'We can do that, but it'll push X out. Is that ok?' And if it's not ok, reasonable management will either pick a priority or get you some help to get them both done on time.
If you're often getting feedback that you 'need to get them both done by Friday.' you might want to evaluate if your management has their act together.
> If you're often getting feedback that you 'need to get them both done by Friday.'
My response is always that I’ll try, and we’ll see which one ends up half-finished on Friday. This either gets them to pick one, or assume everything will be fine until Friday, when it blows up in their faces.
I don’t think I’ve ever had someone (even the manager) blame it on me for some reason.
I didn't have time to go over all 50 but I do like #3, "I have confirmed that someone else can articulate what problem I am trying to solve."
Too often I see devs go down some deep rabbit hole to solve a problem no user has ever had, and I wish they'd have talked to me first about it.
But the author of this article could have generalized a lot here, many of these could be summed up by the (admittedly less interesting) "I know how to communicate clearly and do so frequently with my team."
It would make my life so much easier as a product manager if my engineers would feel comfortable to question themselves and me about what is the value of what they are doing .
This is useful a for a whole lot more than SE. I've started teaching a
Research Methods course this semester and I think I might hit the
students with this list just for giggles.
This is good. It’s been a while since I found an article about software development worth bookmarking.
I think anyone should be expected to write a simple bug report, with reproduction steps and expected versus actual result. There are a lot of people out there who don’t do this simple, necessary task well!
I guess that's inspired by the famous "plan to throw one away (because you will, anyway), from Freed Brooks if I remember correctly.
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.
If the point was "write a prototype/less efficient version prior to the more time consuming but better quality solution" then maybe they should have written that.
The connotation with plan B is you do plan A, then if it doesn't work, you do plan B. If you are supposed to implement plan B first then really plan B is plan A.
115 comments
[ 7.9 ms ] story [ 168 ms ] threadIt's appropriate to put this one first because it shows up in so many of the problems that follow.
Easier said than done when there's a deadline pistol pointing at your head. You gotta get stuff done. Show progress. Writing any kind of specification is just a slippery slope to Waterfall, geez. There's no time of any of that namby-pamby talking to and watching users BS. They don't know what they want anyway! Real developers ship!!
"I can articulate precisely what problem I'm trying to solve" is not just on that person. It is a function of their collaborators – product/program/engineering managers and other engineers around them.
If you are in a culture where it is acceptable to send tasks at each other without much context, and with harsh deadlines, and with a perf management system that rewards execution under such conditions, then you will get precisely the opposite of someone who can articulate what problem they are trying to solve.
In fact you will get a culture where asking questions for deeper 'why' understanding will be seen as disruptive.
Interesting cross-over with Mark Burgess's Promise Theory, where a promise serves somewhat as a single discrete expectation.
At this point in the list we start to diverge from what engineers/developers are allowed to know in the modern enterprise. Here is where we start to get push back from the Program/Product managers, Scrum Masters et al. To proceed further down the list is to remove the added communication channels between engineering and the business.
Where is the company that gives engineers enough freedom to satisfy all 50 points?
I also realized, I'd put a small asterisk on "I have recently profiled the performance of my system," as well. I would expect that an engineer would do at least some minimal profiling of their code in order to make sure it's not too slow in itself and doesn't excessively slow down any calling code, but for the most part, with a running production system, it's generally safe to assume that performance is good enough unless you've been shown or told otherwise. And I think that all still fits into the spirt of the expectation as well.
So that's not what they're advocating. Though I think they're 100% wrong on that point, and most managers would probably think so too.
Same for single threaded vs parallel etc.
I hope this guy has a complimentary list of 50 things for other roles.
This kinda stuff always reminds me of someone making a PR for something like a react component that lets you choose a time zone. It can be a 100 line simple thing or it can be an 800 line monster with files for typescript types thorough tests, etc. I prefer the former but I feel the author would expect the latter.
which of those besides #3 requires day-to-day interaction with another engineer?
and i'd expect #3 to fall out of sprint planning, or just talking with your coworkers about your work.
I work on a team now where we get huge scopes of work and a couple people will tear that work down and would answer these questions as they do so. However, most teams I've been on deal with far more interrupts than the team I'm on now does. Those interrupts are lemented but justified by the business and definitely impact an engineers dedication to a given projects. Interrupt driven work is a sort of split brain problem that I think gets in the way of answering these kinds of questions because it removes the time that an engineer would otherwise spend entrenching themselves enough to know the answers and problemscape.
which is totally fine, most of those things don't need to be done explicitly. (as such they take less time than many commenters seem to think they would.)
being able to articulate something doesn't mean that you've taken the time to do so. just that you've generally thought about your task enough before starting it that if your boss asks you that question, you can produce a coherent answer in a timely fashion.
I don’t believe this is possible in an average company.
If these were actually the bar, everyone in our company (including me) would get fired, and nobody would ever get hired again.
On the other, I can easily imagine the reaction from most project managers if they'd asked me put together an estimate for fully achieving all of these on any given project. Some of them would involve sitting in on business strategy meetings, which is a pretty far cry from the level of involvement I generally get! It's sometimes hard to even get hold of representative hardware to test on.
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 professional expectations (I can schedule my time well). In neither case is there real advice for people who actually struggle with some of these areas.
My item number 51 would be... "I can articulate my point in a more compelling manner than an incoherent collection of 50 things I don't like"
He’s writing a list as part of his imaginary shower argument with his boss and coworkers as to why they are all inferior and he’s perfect and why all the problems they are facing are easily attributed to his list of 50 points of things he feels he does that they are failing to live up to.
At least that’s my take away.
Mind that this instinct was born from prior experience with my own imaginary shower arguments.
Put differently, something you consistently find when you postmortem incidents where people have lost their SA is that they thought at the time they had full SA. They only notice they've lost it when things are clearly going downhill.
So it's important to regularly re-ground yourself with reality even if you think you don't need it. That's a critical component of maintaining SA.
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.
And it's showing. There is so much emphasis on communication, people started equating quantity to quality. "Just talk more, that's what great communication is about" wouldn't be an observation too far from the truth.
Far too little is invested into researching what makes quality communication. It's just the same old rational arguments against rational arguments, day in, day out. For a field entirely about managing and sharing information, be it to machines or to people, that's pathetic.
If people are so certain it is better and believe it is important, let them stake money on it and do research. Until then, the cat is both dead and alive.
Clear lines of communication
Culture of communication
Strong vision and storytelling
Open discussions and inclusive of disagreements
Managing "up"
etc
Communication is hard.
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.
That's not a high bar, it's an arbitrary hoop. It'd be like saying "I always know which processor cache my variables are sitting in". In modern languages it may be literally impossible to look at a block of code and know what's sitting in the heap vs. on the stack, and the heap is often broken into many different components only fully understood by the compiler/interpreter/VM writers. We want to abdicate responsibility of this kind of memory management to the interpreter, just like we want to abdicate responsibility for handling processor cache levels. If you can articulate how all the data you use is laid out in memory all the time, you are majorly micro-managing the runtime.
Agree with the documentation thing though.
Now, it's possible to argue that writing performant software is not important. The prevailing modern sentiment definitely seems to be "The compiler / interpreter takes care of that". But given his track record of delivering high performant running software, and the trend in computing towards sluggishness, I'm trending more and more towards his camp, than the "don't micro-manage the runtime" camp (which is starting to feel more and more like a thinly-veiled "I don't want to have to think about it").
Edit: A summary post he wrote as a source https://cellperformance.beyond3d.com/articles/2008/03/three-...
The quote I'm arguing against is "I can articulate how all the data I use is laid out in memory." Indeed, writing performant code is not important, most of the time. It is critically important a small amount of the time (actual percentages heavily dependent on the type of software), and yes, in those times, understanding the architectural realities of the hardware is somewhere on the list of things you need to understand to do so, just below a solid understanding of complexity analysis, a wide knowledge of useful data structures, proper design of queries and use of indexes (if relevant), etc. A good software engineer does not say "I always know exactly how all my data is laid out in memory", they say "I know when and how to care about that, and the rest of the times I ignore it." Just like they do with many, many other concerns. Anything else is just premature optimization. The most important problem solving skill by far is knowing what you can safely ignore.
Unfortunately, in practice, it's not possible to be oblivious of the layout of data in memory if we want to write fast code. The CPU/memory speed disparity graph [1] shows the new reality for programmers: the slowest part of a program is bringing data from RAM into the CPU registers. Fortunately, modern CPUs have very fast caches that help amortize this cost and it's the responsibility of the programmer to organize data to take advantage of that fast hardware—the compiler cannot do it. That's why two functions, with the same algorithmic complexity, and which compute the same result, can have an order of magnitude of difference in performance between them [2]. The famed sufficiently smart compiler that can do those transformations does not yet exist as far as I know.
[1] https://gameprogrammingpatterns.com/images/data-locality-cha... [2] https://play.rust-lang.org/?version=stable&mode=release&edit...
"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.
I'm confused. The blog post is written by Adam Johnson. Are you referring to Mike Acton or Adam Johnson?
I never heard of Adam Johnson before this HN post. From his books, he appears to be an expert in Django. Yes, I agree about Mike Acton and his ideas around Data-Oriented Design. It sounds like a very interesting approach to programming in a resource constrained environment.
> It sounds like a very interesting approach to programming in a resource constrained environment.
It's more of an approach that is maintainable and straightforward, and only coincidentally (well, not really...) also straightforward and fast to execute.
For example, my new data management system can also do many traditional relational database table operations. If you want to do fast analytics or queries, then it can do it better than the competition. For basic stuff, other RDBMS solutions will surely get the job done; but if you want to build a pivot table against values in a 10M row relational table then this is the tool you want: https://www.youtube.com/watch?v=2ScBd-71OLQ
My product manager was fired a while ago and no one has replaced him formally yet. A C-level guy is micromanaging my team's work now and he sucks at it. I really miss being able to push back on these conflicts.
My response is always that I’ll try, and we’ll see which one ends up half-finished on Friday. This either gets them to pick one, or assume everything will be fine until Friday, when it blows up in their faces.
I don’t think I’ve ever had someone (even the manager) blame it on me for some reason.
Too often I see devs go down some deep rabbit hole to solve a problem no user has ever had, and I wish they'd have talked to me first about it.
But the author of this article could have generalized a lot here, many of these could be summed up by the (admittedly less interesting) "I know how to communicate clearly and do so frequently with my team."
I think anyone should be expected to write a simple bug report, with reproduction steps and expected versus actual result. There are a lot of people out there who don’t do this simple, necessary task well!
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.
The connotation with plan B is you do plan A, then if it doesn't work, you do plan B. If you are supposed to implement plan B first then really plan B is plan A.
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”