undefined | Better HN

0 pointsSomeCallMeTim10y ago0 comments

    I don't subscribe to the school of thought that 
    values engineers lower on the stack more than 
    those higher up

Meaning developers who understand low-level details vs. developers who just wire up high level libraries?

I've done the full range, from entire games written in assembly language and embedded C code, through high level full stack development with NodeJS, Python, and other languages.

The low-level coding is far more skilled work than the high level coding. Instead of most of the work being "how do these plug in to each other?", it's how exactly does my code function with respect to all of the potential events additional threads, and how all of the edge cases interact, and what is causing this obscure bug?

While that may not seem intrinsically harder, none of these are typically something you can Google or search StackOverflow for the answers on. So you're really just on your own. And developers who have grown up on "Google all the answers!" often hit a wall when they need to apply real problem solving skills.

Luckily I can find enjoyment in many levels, since a lot of the jobs I've found recently have been more of the "full stack" or "mobile development' category. It's easy and fun work.

I also have little problem piercing the magic and understanding how things fit together, but that means that I end up with opinions on many topics divergent with the crowd. For instance, I avoid writing Android/Java or iOS/Swift, and instead use cross-platform development stacks exclusively. Yes it means an entire extra layer of complexity, but it also means I write the app once for all target platforms. Far too big of a win to ignore.

0 comments

5 comments · 3 top-level

rimantas10y ago· 2 in thread

Sorry, that way you do not write an app for all of the platforms. You write for none of them it just happens to run on one of them.

SomeCallMeTimOP10y ago

I test on iPad, iPod Touch, a half dozen Android devices, and on emulators. Works well everywhere, even with platform-specific differences in design to match different platform paradigms. And I have happy clients.

I've run into this attitude before, though. It seems to be the last bastion of denial of folks who have spent a lot of time learning one platform and who don't want to learn something new. Sorry, but there are better ways.

loup-vaillant10y ago

Err, what do you mean? I once wrote the embryo of a game with Qt, it ran on 3 environments (GNU/Linux, Windows, Android). What to I care that I write for "none" of those platforms if it "happens" to run on all 3?

rwallace10y ago

> The low-level coding is far more skilled work than the high level coding. Instead of most of the work being "how do these plug in to each other?", it's how exactly does my code function with respect to all of the potential events additional threads, and how all of the edge cases interact, and what is causing this obscure bug?

I've done the full range too, and I don't agree that low-level involves more skill. I think it involves different skills. When you're working high-level, you don't have the above questions so much, to be sure. Instead you have questions like, what are the relevant business rules? Which ones are stable and which ones are going to change? Does this user interface suck? Is the program giving answers that actually correspond to reality? Does anyone want this product in the first place? Different questions, but not easier to answer.

tetha10y ago

> While that may not seem intrinsically harder, none of these are typically something you can Google or search StackOverflow for the answers on.

From my multi-threaded background - The problem is, the code looks simple and the code actually doesn't get more complicated. Usually, the code you need to write in 90% of the time actually becomes easier to write for most people, because they can work in rigidly defined boundaries.

However, explaining why this part of the code base is safely threaded and scales vertically across multiple cores, and how we avoided multiple non-obvious bottle-necks, and the optimization the software 3 services in the past matters... that's going to take hours. And at that point, we haven't touched lock-free operations yet.

And after that, understanding how to design an architecture from scratch, how to interact with the network and the kernel properly, how to enable distribution of the application in an elastic manner... yeah. Let's get a room.

And these kind of systems are exactly the systems which benefit from the SICP-approach. Thread pools, message queues, databases, the network, lock-free data structures all are well-understood components we can combine in structured manners.

j / k navigate · click thread line to collapse