I might be canned for this here, but, I see that enterprises have a lot more work of the fundamentals, simpler sort than startups. At startups, I worked with 100s of libraries not understanding, or not having the time to even look back at things we did. At enterprises, there are a lot of low hanging fruit, which when applied magic CS pixie dust, becomes more performant (to a lot of people).

This is one of the reasons why I moved away from product side programming to IT. My brain screams in pain, when I do lot of context switches, and I figured this is not going to make me a better programmer. The fun stuff is in handling data, not learning layers of apis(for me).

Now working in enterprise is not for everyone - the politics etc, but for me, it still beats the pain of working in a smelly, loud, fast context-switching, agile-kanban startup.

    I feel miserable doing the kind of programming I do 
    nowadays! I wish I could go back to simpler times, where 
    I actually had to reason about algorithms, data 
    structures, hardware, etc...

I don't subscribe to the school of thought that values engineers lower on the stack more than those higher up, especially since there seem to be a lot more new jobs of the latter sort and we all need to make a living, and there are plenty of cool problems in those spaces (algorithms, data structures, performance... it's all there).

But I think the lucky ones are people who get to work low enough relative to their knowledge where it doesn't feel they are dealing with endless abstractions and layer upon layer of magic.

    The startup I work for moves so fast that I'm forced to 
    use other peoples open source projects without even 
    having the time to read the source.

:( sounds to me that this might be more the problem. And worse is I suspect it's common.

    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.

> 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.

> 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.

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.

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.

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?

I think he doesn't necessarily imply anything about being high or low in the chain. But about beauty and understanding.

SICP is one example, but I bet it's even possible to be happy coding GUIs or any other rather mundane things if one does it with an elegant toolset. For example, Oz comes to mind.

Some modern tools are not pleasing to use, often because architectures are a mess. Things move forward too quickly.

What's Oz?

A worse problem would be simulating linux in your head as you methodically review the source.

I was trained on Scheme 20 years ago. Scheme was the moment when I felt I "got" programming right (before that I did lots of Pascal, basic, assembler,etc).

Now I do Python. And with Python I "got" something too : writing tools, coding, etc. is not like mathematics (like Scheme) anymore. It became a social activity. I'm in the field of ERP right now (arguably not the most theory-oriented stuff). It's because I spend most of time using API's by other and making API's in the hope that they will be used by other (none of those API being worth much in terms of computer "science" (stuff like algorithm). I'm also building tools to augment productivity of other people; which is also quite social.

So from the abstract Scheme programming, I've moved to Python social programming. That keeps me happy (I must confess that studying Voronoi diagrams, or 3D structures packing remain what made me really tick :-) )

And to make this really annoying, you still need to know low-level algorithms and data structures to make it through most interview processes. What they should really do is give you a crappy API doc and have you make it do something useful.

You're just applying at wrong companies.

Please take advantage of your job mobility. Changing jobs in our line of work isn't as simple as flipping a switch, but you still are in so much demand. There's no need for you do engineering work you're dissatisfied with.

> I feel miserable doing the kind of programming I do nowadays! I wish I could go back to simpler times, where I actually had to reason about algorithms, data structures, hardware, etc.

Join the TXR project:

http://www.nongnu.org/txr

http://www.kylheku.com/cgit/txr/tree/

I made some 3000 commits all by myself since 2009. The main reason why this exists is the above: a project where I can stuff ideas, algorithms, whatever, into a coherent whole that has regular releases and is well-documented externally. And this coherent whole is useful to me in many ways.

TL;DR but it reminds me of Awk...

Awk also has an input scanning sublanguage which implicitly marches through data, and that language can evaluate expressions and functions in another sublanguage. That's where the analogies end.

>> moves so fast that I'm forced to use other peoples open source projects without even having the time to read the source

This.

Moving fast, sprinting, only looks like you are making progress. At some point the debt comes too much

In a startup context, the trick is to make sure the technical debt comes due after the point at which you find out whether you've got a product people actually want in the first place.

Have you considered getting into embedded development? You tend to be dealing with much lower level code and closer to the hardware. It's fun :)

Thanks for this comment. Actually I have considered embedded a lot. I love C, specially free standing C.

I will probably move to embedded soon. Problem is I have lot of experience with iOS but not that much experience with embedded, I'm willing to get a pay cut just to get out of iOS but there's a limit of how low I can go.

There's also a lot more iOS jobs than embedded jobs!

edit: Other than C, I'm very curious about rust and nim-lang. I do not know C++ though. Hope that won't be a problem.

Yes making career moves from one technical field to another can be difficult - I hope you manage to find somewhere that'll take you on without putting you over a barrel.

I've found that it entirely depends what level of embedded development you want to enter - for instance I mainly work with C++ and MSQL databases on our platform - because our main device runs linux this makes sense. But other related products that we sell run on bare metal and are written in pure C.

Having a strong knowledge of C will most certainly get you far in this field, but perhaps learning the ins and outs of C++ wouldn't be such a bad idea if you have the spare time - the more niches you can fit in the easier it will be to pick up that job you really want.

Serious question: What is stopping you from going back?

I'm naive but curious and I do not want to make guesses.

I wonder how are we going to preserve knowledge about programming from first principles if, under pressure from corporations and lazy peers, no one does it anymore?

It's mostly that I got 'stuck' with iOS. Once you specialise it's hard to get out. If I change jobs now for anything other then iOS, I have to take a pay cut and I need to find someone that will hire me without any previous experience in... embedded, for example.

There are also a lot more of this 'poking' jobs when compared to first principle coding jobs. Specially for someone like me who never worked for huge corporations.

Not _that_ hard. Gradual transition should work.

If you like videogames, learn some OpenGL ES, apply to mobile game development position, if you’ll like the area, you’ll be able to continue career developing games for other platforms. If you’d like to move to MS stack, learn some .NET, then look for Xamarin iOS jobs, you’ll be able to continue career developing .NET for Windows. If you enjoy hacking, seek a job in a company that makes UI test automation tools for iOS, or iOS-related security software.

You already have experience dealing with all those iOS weirdness, you might be able to minimize or even negate that pay cut.

I think nowadays the most important business in a company is to built things atop fundamental things. For example, we build apps atop Cocoa, web atop ror. That is the business stop us from going back.

Well, to be honest, that's why there are no iOS apps worth a god-damn. We got a bunch of junk as apps (programs now). So much wasted effort and time.

Closed source? Decompile the fker.

Sure. That makes it easy to reason about the code, see the abstractions clearly (at least as clearly as the author intended), make minor changes and submit patches upstream, recompile it with different options, ...

Oh, wait.

If you don't have time to read the open stuff, you probably don't have time to pick apart the closed.

I'm sure the lawyers in your company will be really happy to hear that.

And why exactly you're wasting your skills on something as pitiful as this? There is a lot of work out there for people who can build complex solutions from the first principles.

Even piecing together systems out of existing components significantly benefits from knowledge of first principles.

Maybe. But he obviously feels miserable doing this. What's the point of being miserable while there is a lot of much more fun things to do?