12 ms·

I honestly can't remember a time in my career when I've looked at a codebase and thought to myself "what this dev really needs is a more thorough understanding

I honestly can't remember a time in my career when I've looked at a codebase and thought to myself "what this dev really needs is a more thorough understanding of CPU pipelines and virtual memory". Ed Yourdon once wrote something like "No project was ever cancelled because the developer couldn't address the serial bus". I'm much more concerned with bootcamp graduates not understanding good class design or appropriate unit testing than I am about any lack in low level mechanics. I don't know if SWE is getting better or worse, but I do think that most SWE operates on a much higher level of abstraction than it used to, and I think that's good thing.

grogenaut 7y ago
I don't know of any project that was ever cancelled because of poor class design or lack of unit tests either. Sure they were hack jobs but if they met the needs of the customer then they were successful. Likely successful enough to be worth hiring you to fix those shortcuts. And allow you the free time to complain about craftsmanship on a public forum.
- alrs 7y ago
  I absolutely have. A bonkers class hierarchy and no unit tests means that velocity will bog down to a crawl or even start running in reverse.
  - quickthrower2 7y ago
    Absolutely. But to management it can look like another reason. For example it could look like “Not enough revenue to pay all the devs”. But you only need a big team because it’s basically spaghetti code and there’s a lot of fires to put out. I’ve seen this. It’s also really hard to convince managers even technical ones who are not in the code that there is complexity to deal with. “But it’s just a [something that prima facie sounds easy] should be easy!”
- 0x8BADF00D 7y ago
  It depends on the industry vertical. If you have heisenbugs in your software, let alone poor design / lack of unit and functional tests in one industry, it may not matter. But it may end up killing someone in another industry.
pixelpoet 7y ago
I'm in computer graphics, and find myself thinking "this dev really needs to better understand memory layout and computer architecture" all the time when I look at even basic code. A perfect example of this is looping over some range of pixels, and many will just go ahead and do for (x) for (y) setPixel(x, y, f(x, y)). There's no logic error here but it's still terrible when dealing with images in the usual memory order idx = y * width + x. It seems like many people have no idea how even basic abstractions (such as the aforementioned pixel indexing example) work, and have no performance expectations because they don't code in any systems languages. People who are aware of such issues and still can structure large codebases well seem to be getting more rare to me, at least. In the 90s there were so many incredible demoscene programmers, and now... hmm... (A related thing I wonder about is, where is the von Neumann or Newton of our times? There are more people around than ever, nutrition and medicine and poverty is globally better than ever, ...)
- QuestionPixel 7y ago
  I'm currently studying EE and would like to get into embedded programming/semiconductor design, could you explain the optimal way to loop over the pixels if not with two nested for loops? Would it be something related to how in memory it's effectively a 1-D array?
  - kamih 7y ago
    At the very least, the inner loop should be over X, since that is how the pixels are packed.
  - RhysU 7y ago
    It is precisely the linear ordering in memory. Whether X-then-Y or Y-then-X is best depends upon if the data is stored row- or column-major.
  - jfim 7y ago
    The loops should be inverted. It should be for y, then for x, which accesses the memory in a linear fashion instead of in stride. This presentation (PDF) explains why: https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf
mrbonner 7y ago
Yes I do think about this occasionally at work for math heavy (LA and in house built convex optimization) problems. I cringe when I see tight loop with stream/functional java API. It’s not zero cost abstraction you know!
throwaway_45 7y ago
A bootcamp person can learn most of these things. It just seems with some of our recent hires they don't seem to want to learn this stuff or maybe it doesn't really matter for react devs. And these things do make a difference. L1 cache is faster than L2 cache which is faster than L3 which is faster than memory which is faster than hard disk etc. You want your code to keep things within those limits to make things faster. Or for example if you start using virtual memory and paging to disk you might want to switch algorithms. For example you might want to use merge sort instead of quick sort if you don't have a lot of ram and you have to go to disk. However if you have 128GB of memory and mostly randomized data you want to use quicksort. This is kind of trivial example, but I think this stuff is somewhat important.

grogenaut 7y ago

I don't know of any project that was ever cancelled because of poor class design or lack of unit tests either. Sure they were hack jobs but if they met the needs of the customer then they were successful. Likely successful enough to be worth hiring you to fix those shortcuts. And allow you the free time to complain about craftsmanship on a public forum.

alrs 7y ago
I absolutely have. A bonkers class hierarchy and no unit tests means that velocity will bog down to a crawl or even start running in reverse.
- quickthrower2 7y ago
  Absolutely. But to management it can look like another reason. For example it could look like “Not enough revenue to pay all the devs”. But you only need a big team because it’s basically spaghetti code and there’s a lot of fires to put out. I’ve seen this. It’s also really hard to convince managers even technical ones who are not in the code that there is complexity to deal with. “But it’s just a [something that prima facie sounds easy] should be easy!”
0x8BADF00D 7y ago
It depends on the industry vertical. If you have heisenbugs in your software, let alone poor design / lack of unit and functional tests in one industry, it may not matter. But it may end up killing someone in another industry.

pixelpoet 7y ago

I'm in computer graphics, and find myself thinking "this dev really needs to better understand memory layout and computer architecture" all the time when I look at even basic code. A perfect example of this is looping over some range of pixels, and many will just go ahead and do for (x) for (y) setPixel(x, y, f(x, y)). There's no logic error here but it's still terrible when dealing with images in the usual memory order idx = y * width + x. It seems like many people have no idea how even basic abstractions (such as the aforementioned pixel indexing example) work, and have no performance expectations because they don't code in any systems languages. People who are aware of such issues and still can structure large codebases well seem to be getting more rare to me, at least. In the 90s there were so many incredible demoscene programmers, and now... hmm... (A related thing I wonder about is, where is the von Neumann or Newton of our times? There are more people around than ever, nutrition and medicine and poverty is globally better than ever, ...)

QuestionPixel 7y ago
I'm currently studying EE and would like to get into embedded programming/semiconductor design, could you explain the optimal way to loop over the pixels if not with two nested for loops? Would it be something related to how in memory it's effectively a 1-D array?
- kamih 7y ago
  At the very least, the inner loop should be over X, since that is how the pixels are packed.
- RhysU 7y ago
  It is precisely the linear ordering in memory. Whether X-then-Y or Y-then-X is best depends upon if the data is stored row- or column-major.
- jfim 7y ago
  The loops should be inverted. It should be for y, then for x, which accesses the memory in a linear fashion instead of in stride. This presentation (PDF) explains why: https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf

mrbonner 7y ago

Yes I do think about this occasionally at work for math heavy (LA and in house built convex optimization) problems. I cringe when I see tight loop with stream/functional java API. It’s not zero cost abstraction you know!

throwaway_45 7y ago

A bootcamp person can learn most of these things. It just seems with some of our recent hires they don't seem to want to learn this stuff or maybe it doesn't really matter for react devs. And these things do make a difference. L1 cache is faster than L2 cache which is faster than L3 which is faster than memory which is faster than hard disk etc. You want your code to keep things within those limits to make things faster. Or for example if you start using virtual memory and paging to disk you might want to switch algorithms. For example you might want to use merge sort instead of quick sort if you don't have a lot of ram and you have to go to disk. However if you have 128GB of memory and mostly randomized data you want to use quicksort. This is kind of trivial example, but I think this stuff is somewhat important.