The Full Stack, Part I

Re:The Full Stack, Part I by tom_b on Thursday December 02, 2010 @03:42PM (#1963579)

I started as a performance software person, from memory and cache conscious algorithm design in grad school, to network stack testing, to web server/db server/client-side performance testing and optimization. It is an excellent way to develop that feel for the big picture of how things are working. In enterprise software, there used to be a lot of low hanging fruit and it was fun to get "heroic" results with simple SQL tuning.

The flipside of that experience and mindset is that now, as I try to shift my way towards more functional and declarative programming styles is that I sometimes get sucked into the premature optimization black hole - I overthink rather than just doing some simple exploratory programming.

I keep telling myself I'm going to implement some fairly large project using nothing but lists and a Lisp to break it down.

[ Parent | on HN ]

Re:The Full Stack, Part I by ohyes on Thursday December 02, 2010 @04:41PM (#1963780)

I get around this by implementing the abstract version of my code first; I then implement the abstractions that I used in the abstract version of my code. So I'm not even worried about running code until I have a general idea of what I want it to be doing.

I obviously then rework stuff as I learn that my assumptions were totally wrong, but this way I've started from an incorrect conceptual model; rather than an incorrect full implementation. I think this makes it easier to manipulate.

edit: And I guess the point of that is that according to XKCD, I start at sociology, and work my way down the stack until I get to whatever language/libraries (hopefully not Math) I'm actually programming in. Like some sort of crazy fractal.

[ Parent | on HN ]

Re:The Full Stack, Part I by chipsy on Thursday December 02, 2010 @03:54PM (#1963608)

It's definitely a fine line between taking a "bottom-up performance" mindset and a "premature optimization" one. Way too often, I'll start approaching something with a fast-complex solution, spend some hours on it, run into major bugs, and then quickly turn around, do the simple thing instead and usually get it done in under half an hour.

I have the feeling that I can only really overcome this by knowing the domain well enough that I don't feel the urge to take on such big problems anymore. It seems like there's a vast middle ground of knowledge where you know enough to not be naive, but you don't know enough to understand what you're getting into with the harder solution.

[ Parent | on HN ]