Hacker News Reader

Comment by numair | Hacker News Reader

Programming is so much more fun and awesome now. Everyone has a computer, and has their computer on them 24 hours a day. Whether it's a website or a mobile app, you're able to immediately get things in the hands of your "normal" friends and see what they think.

The development side of things are also better. All of these open-sourced, internet-networked tools/libraries/languages allow you to build really powerful stuff really quickly. Yes, there is a huge quality and maintenance problem, with lots of people writing libraries they instantly abandon, but I think this just forces you to read lots of source code and become a better programmer.

Build more powerful stuff, faster, and get it in the hands of more people, faster. What a time to be a programmer. The article does a good job of noting the problem of distraction, but I think that has always been an issue, and why we have always seen anti-social traits among lots of successful developers. Tuning out the allure of being young and having mindless fun in the 90s to focus on code is no different from tuning out the allure of being young and having mindless fun today. As for older people, well, it's always been a challenge to be super-focused and dedicate time to learning new things while dealing with household/adult responsibilities.

This is a very special moment as a developer. It is like being in the business of rock 'n roll in the era in which radio and television took off, which made it possible to create music that ended up broadcast around the world within weeks. If you can stay true to the roots of the code, and avoid all of the weird get-rich-quick types that have entered the scene, you can have a lot of fun right now.

The past wasn't any better, and the future can't be predicted. The time is now.

View on HN

Programming is far less fun now, and more painful than it used to be: stupid management practices (agile, scrum, ...), broken and poorly documented 3rd party libraries, code reviews, pair programming, politically correct unit tests, it goes on and on. Check my previous HN postings for rants, if you'd like.

It used to be that your computer had a compiler, and editor, and a shell, and you would go to work, writing code. Now, in the age of programming by google, you are left with the much duller task of gluing together other pieces of code. It's boring, and there are so many distractions -- the ones noted above, as well as Facebook, Buzzfeed, etc.

Now there is one other thing that's going on. Most of us are working pretty high up the stack. I suspect that if you are working on low-level algorithms (for AI, database internals, DSP, ...) that programming remains a fun activity.

It sounds like you enjoy writing code itself more than the process of building software. I get the same sense of wonder and excitement when I get an app to successfully do something I thought up in my head whether it's just attaching up a Google API to get a map or location picker integrated and working or if I'm coding out the whole feature myself.

I have a lot of respect for hardcore "coders" (I feel like that term has a pejorative connotation in tech, but I don't mean anything bad by it). But I think there are plenty of people out there like me as well. I consider myself an engineer, not a programmer. I solve problems and build things. Writing code is just one of the major tools in my arsenal to get things done.

I think there are still tons of options out there for people who like writing lower-level code, but it's moved into areas like embedded systems and scientific lab tools. All the coding work for most of the common stuff has been basically commoditized already.

The funny part here is that in many cases it is still far easier to build stuff from scratch than to glue someone else's poorly documented shit together.

Yes. So many libraries are engineered to solve everyone's problems, you can spend hours, or days, figuring out if it is engineered to solve your problem. It's like searching for a needle in a haystack you aren't sure has your needle.

EXACTLY. In a previous HN comment I ranted about this exact topic. My threshold for adapting something very general to my specific case is now much lower than it had been.

To restate my position using your terminology: I prefer programming (creating from scratch) to engineering (integrating) because the components that a software engineer has to work with are so often unusable. To repeat a rant from an HN comment of a few weeks ago: I am working on a system involving Jetty, Postgres, and a connection pool. The first two components are pretty solid, and there is no shortage of Java connection pools to choose from. But getting them to all play together defeated me. Documentation for Jetty and for the connection pools is just terrible, and highly version specific. The APIs keep wiggling around as the versions change. I finally gave up on doing things the "right" way (configuring everything in XML), and also gave up on integrating a connection pool. I wrote my own very simple one.

I don't really see how this means things are worse now than they used to be. You can still write things from scratch now (just as you did). But "back in the day" you had much more limited options for libraries, so you were not always able to glue stuff together, and often forced to write things from scratch. I'd argue that means it's better now than it used to be.

It's a matter of expectations. Working on my own projects, I can rewrite and ignore existing software to my heart's content. If I am working with others, there is a very strong expectation that 3rd party software will be used whenever possible, and that I will participate in other engineering practices/fads that are judged to be beneficial. I don't mind doing things that have a good rationale for the problem at hand, but very often a team will do X because X is supposed to be a good thing to do. Cargo cult engineering, if you will.

> It's a matter of expectations. Working on my own projects, I can rewrite and ignore existing software to my heart's content. If I am working with others, there is a very strong expectation that 3rd party software will be used whenever possible, and that I will participate in other engineering practices/fads that are judged to be beneficial

Isn't that just part of 'being a professional' tho?

Being a "professional" means thinking. There is much unthinking adoption of the popular tools and approaches.

You cannot avoid using all those convoluted, unnecessary layers in many cases, even if you really want to. In JVM you're confined right on a top of a horrible pyramid. And in web it's even worse.

I think the reason such rants pop up occasionally and are often criticized is because the field was started by what you call "hardcore coders" - people interested more in the building part (and tweaking, and adapting) - but as it became more and more profitable, it got co-opted by the people who are more interested in getting stuff built, without paying much attention to how its built.

Or the way I look at it, it was once nerds' playground, and those nerds are now an unwanted minority of the growing software field. Hardware is going through the same thing now, with hardware hackers getting replaced by startups.

Now, I don't mean that in an offensive way. It's simply a clash of two cultures co-existing within the same field. There's lot of misunderstanding because of that. For instance - I work in a software company; there are 30 programmers on my floor alone, but only around 3 or 4 I'd consier "my kind" of programmers. The rest think I'm the office nerd, who likes weird shit (electronics? Lisp?) and for some strange reasons likes to (omg!) code after work, instead of running or going to a concert. When I first learned programming, pretty much every programmer I knew was like me. Now we're the minority.

> Or the way I look at it, it was once nerds' playground, and those nerds are now an unwanted minority of the growing software field.

I assume you have to be talking about some very specific subfield, because the practice of 'writing software in exchange for money' is over half a century old.

It seems to me that people doing software for money back then were "different breed" than those coming to the field today, now that software is suddenly hot and an easy career choice.

Software has had plenty of "hot" years tho and I'm not sure I can remember when it wasn't an easy career choice except maybe in the depths of some of the busts.

> I think there are still tons of options out there for people who like writing lower-level code, but it's moved into areas like embedded systems and scientific lab tools. All the coding work for most of the common stuff has been basically commoditized already.

If that were true, there wouldn't be new JS frameworks coming out every month. Those "hard core" coders are also the ones making the frameworks. Which isn't a bad gig, especially when you can sell educational materials to teach people the framework you made. :)

Hardcode coder is an oxymoron; coders are the ones attending an 8-week bootcamp then cutting and pasting Javascript from Stackoverflow. Hacker is probably what you mean.

Yeah, that's the connotation I was trying to avoid, that's what I was talking about...

>It used to be that your computer had a compiler, and editor, and a shell, and you would go to work, writing code.

By "hardcore coder" I just mean someone who thinks ^that^ sounds like a lot of fun.

And it does sound like a lot of fun.. I just prefer to be able to augment it with StackOverflow/Google :)

It's because programming has evolved. More business owners are also already tech savvy because they grew up with a computer, Ipad, and phone.

In the beginning, programming was more fun. No oversight, bosses that don't really know what you are doing, programming at one point in time was treated like magic.

You glue together other pieces of code because in most cases, because the wheel has already been invented. This really was the dream of open source and with all of the free software and libraries out there, it's becoming a reality.

It's also going to drastically reduce the wage of a programmer over time. Most businesses don't need to hire an engineer to create a complicated library. They can hire someone with much less skill to use an already existing library to get what they need done.

Since the skills to get the job done will decrease, the supply of potential developers will increase and wages will decrease.

I suspect that the jobs are just changing, without a significant impact on wages, at least for the average Joe. Consider this analogy:

If everybody has to re-invent the wheel, you have to put all your resources toward getting someone to invent the wheel for you, so you can compete with all the other businesses using wheels.

Once everybody can re-use an existing wheel, you can aim higher, and put the same amount of resources toward getting someone to combine existing wheels and other parts to make something much more efficient and tailored to your business. And you need to do this to compete, because it's what everyone else is doing now, and a simple wheel just wont cut it.

So yes, someone with the skills required to invent the wheel becomes less in demand, but I would argue that someone who can turn existing parts into a working and customized whole requires just as much, if different, skills, with a roughly equal supply and demand ratio, thus able to demand a similar wage.

My argument that it requires as much skill stems from what others have pointed out. There may be a tool for everything, but it takes a lot of experience and ability to find an acceptable tool for each task amid a sea of tools of varying use, quality, documentation, etc. And it is rare that you can get maximum business efficiency from something cold off the shelf, without someone skilled modifying, configuring, tweaking, combining, etc.

If only there were wheels available. I like wheels, and I know what to do with them. I trust that they will work as specified. The problem is that with software nowadays, the components available are far more complex, and the true costs of using them are not obvious at the beginning of the process. More like Takata airbags.

Heheh, fair enough. I was intending my analogy to refer to high level tools in general. But yes, this illustrates my point, that there is and will continue to be a demand for highly skilled engineers who can identify and dismiss the Takata airbags and locate the parts that best match their employer's business.

Particularly outside startup world. Established businesses in competitive fields are constantly trying to maintain or gain their edge, and don't have time to build from scratch.

This isn't showing to be true despite proliferation over the last twenty years. Most kids don't want anything to do with programming because to most kids, it's a lot like doing math all day. Even as programmers become more enabled to solve more problems, the pace of problems being created is far outstripping the human race's ability to create (or inspire, whatever) programmers to solve those problems. I am willing to put a paycheck on a bet that no sane, knowledgeable person will ever be able to say that "we have enough programmers in the world".

Just wait for all the boring parts of programming to be automated. Then it is likely thay we'll have enough or more than enough programmers.

When the "boring" parts of programming can be automated, so can the "fun" parts, and AI will have "taken our jobs" just like they did down at the toothpaste factory. I'm not concerned about that. When it happens, that's fine by me. I have other skills to fall back on.

It won't happen all at once. There will be a long process of elimination of more and more layers, leaving more and more developers available for the work on the less automatable (more fuzzy and chaotic) side of spectrum. It will take years. At the end all of them will go home and do something else, of course.

Facebook and Buzzfeed sound like awfully solvable problems. Just install Leechblock and set a block for them during work hours.

The rest sounds like mis-management issues, which I think has more to do with lack of analysis than programming itself.

Porting Agile or Scrum to an organization and not checking whether that port breaks things is absolutely insane, but it seems par for the course nowadays (imagine how much shit a sysadmin would get for setting up Apache and his setup refused all requests...ah well).

Same goes for pair programming. Does it work better than the alternative? Yes? Great. No? Knock it off then.

What are PC unit tests?

Code reviews seem like a great thing IFF they work properly. Proofreading, style compliance, teaching, catching errors, etc. If none of those things happen, they are pointless. Might as well swap the company cars with wheel-less Tesla's or something.

It just sounds like you've got the management equivalent of a bad sysadmin going.

>>> same goes for pair programming. Does it work better than the alternative? Yes? Great. No? Knock it off then.

I've worked at small and large companies and I've had the same experience with pair programming. It's done as a means to supplant actual, formal training. It's utilized as a shortcut to get a dev vaguely familiar with the architecture of your system and do rudimentary tasks so they can jump in and start working in a day or so.

The painful downside of not adequately training your developers is tasks take longer, other more experienced devs are sapped by helping other devs who continually ask them questions and keep them from getting their stuff done because they can't find something, or simply don't know the proper process.

I've been on both sides and seems like proper training is really a thing of the past. No company wants to invest the time in their developers to give them the tools and knowledge to really do their job well. As a replacement, you get "pair programming" as a substitute to proper training program.

And yes, I know this isn't the point of pair programming at all. But lately (last three years or so), this is how the companies I've worked at use it.

The ironic thing is several of the companies I worked at had a two to three week sales training which culminated in a test to make sure you knew the companies products inside and out. Developers? Maybe a lunch with a lead dev, or a twenty minute whiteboard explanation about their system architecture.

I'll take pair programming over sitting in a classroom listening to an instructor drone on any day. The one time I joined a pair-programming shop, I thought diving in and being productive on the first day on the job to be pretty great.

Usually I get neither and have to figure it out from the code. I've found that writing documentation for the next person as you figure it out to be a nice way to get started.

I understand (though don't necessarily agree with) most of this perspective, but not the knock on code reviews. I think they're awesome - what could be more fun than reading and discussing other peoples' approaches to problems?

It's a very useful thing to do. Except that most of this discussion should be a design review much earlier in the process.

Design reviews are also awesome! I'm not sure I agree with your use of "most" - I would say that most things discussed in code reviews I've participated in would not have made sense in the design phase. Also, code reviews are as much for the reviewer's knowledge as for the author's.

It seems like you don't like to work with other people. There's a limit to the kind of software you can build entirely yourself.

Yet, this limit is far higher than most people tend to think.

all those things (agile etc) are better than working on waterfall style software with 5000 other programmers at microsoft and massive teams of PMs to coordinate it all. That was awful.

Oh, god. Here's the thing. You are the most right person on this entire page. Programming big projects in the days of yore was awful! It was AWFUL! And the worst part is that the whole waterfall thing is totally wrong. The original paper provided the waterfall as an example of how not to write software! Yet the whole industry suffered for thirty years. And still do, in some shops! Ugh!

really? developing repetitive stuff is fun? I want to re-write low-level mouse driver.

Find good libraries and mash it up to your heart's content!

Repetitive? No. Low-level? Yes, it certainly can be. Engineering a working application by shuttling data between a bunch of pre-written libraries can produce a satisfying result, and it's usually the smart way to design something.

Personally, I enjoy the process of building a clean abstraction more than using someone else's abstraction. If there's a system that doesn't have a mouse driver, then developing one sounds like it could be fairly interesting.

I would not say coding is more fun today. There is more stuff available, true, but the quality of documentation is abysmal compared to what we used to have before.

Also, far more needless layers in between hardware and your code. It is annoying. I want to go back to my cosy VAX/VMS environment.

> but the quality of documentation is abysmal compared to what we used to have before

Who needs documentation if we have Stack Overflow? /s

Seriously, I had to learn React for my new job (not a web dev by trade), and while I don't dislike the framework (a compliment in programming land), a lot of times I had to resort to Stack Overflow for information that should have been provided by the documentation; which instead assumed I already understood how React worked, or forgot to mention that things were different in ES6, or mentioned that things were different but wasn't clear about how.

The worst part is that when I complained about this to my friends they said "oh, React is one of the better documented frameworks out there". At that point I honestly wondered how has any webdeveloper has managed to stay sane during the last decade.

As for fun coding with good documentation, I suggest Processing:

https://processing.org/

.. good luck using that professionally though, unless you get paid for creating interactive art.

they said "oh, React is one of the better documented frameworks out there"

well, consider the ruby language: it is implementation-defined(!).

i got a Rails job without knowing any of Ruby beforehand (and the other party was aware of this). i made myself comfortable in the office and asked: so where's the Ruby manual? they said, "ruby-doc.org". "that's just the API docs, where's the language reference?" i asked. "there's none. maybe you could use the Bison grammar from the MRI source..." "???"

> Stack Overflow

Even in this thread people suggested to write documentation straight there. It is an extremely worrying trend.

> how has any webdeveloper has managed to stay sane during the last decade

Did any of them really manage to stay sane?

> https://processing.org/

Last time I looked at it I could not find a printable PDF reference. Is it possible to generate one?

My quality threshold for documentation was always set very high, because I started my career with VMS. And DEC always had that obsession with comprehensive, concise and clean documentation on every tiniest bit they're exposing.

Hmm, I'm not sure about the pdf thing, but it has a fairly small number of core features[0], which are all documented and can be browsed off-line, and searched through from within the minimalistic editor that it comes with.

You could try looking at the source code of the documentation[1]. It uses PHP to render the site, although the actual documentation of the API is XML[2]

[0] https://processing.org/reference/

[1] https://github.com/processing/processing-docs

[2] https://github.com/processing/processing-docs/tree/master/co...

Thanks, did not notice the XML sources. Looks like it must be possible to produce a decent PDF with some effort.

If you manage, be sure to let the Processing foundation know; I'm sure they'll love a PDF (eBook?) version of the documentation.

I honestly wondered how has any webdeveloper has managed to stay sane during the last decade.

Who said we stayed sane?

> There is more stuff available, true, but the quality of documentation is abysmal compared to what we used to have before.

What did you expect? Nowadays, there is a common expectation, especially among web development libraries, for frequent updates, especially in the cases of bugs, etc. In the eyes of the people, functionality became more important than the documentation (though those people would like to claim otherwise, I'm sure).

The demand is for the new code to be available ASAP. And as a result, the documentation suffers, and the implementations and details change faster than the documentation can be maintained.

The emphasis of maintaining good documentation is further lessened by sources like StackOverflow, which provide the library maintainers with an excuse of "we can skip this step, since it will be covered in SO and countless blogs anyway. It's not like we're the only source of information."

This is just an unfortunate symptom of the modern coding ecosystem. Good documentation requires stability and consistency, which today are discouraged in favor of flexibility and quick turnovers.

> Good documentation requires stability and consistency

Or a good architecture, a decent generation system, and a bit of discipline to write out the non-obvious bits that can't be generated.

Documentation should not suffer from frequent changes. It is easy to keep docstrings in sync with the implementation, they should both be visible at the same moment.

Also, if 99.9% of all those "web frameworks" just die without a trace, the world will become a much better place anyway.

>> but the quality of documentation is abysmal compared to what we used to have

It is, however, more accessible and easily searchable. And also basically free. Many programmers have never bought or own a book related to programming - they learned from all online sources.

>> layers in between hardware and your code. It is annoying.

But it's so much more convenient. In the old days you had to learn all about your graphics card, your printer, your sound card, you'd need a certain driver for your modem or network card... Now everything is abstracted and easy to use.

> Many programmers have never bought or own a book related to programming - they learned from all online sources.

I wonder what the effect of this has been on overall quality of code for this subset. I know that while I've learned more from online sources than books (whether physical or electronic), the lessons I have learned from books are overall above the average quality of all my sources.

I can tell you that the two languages I can confidently say I know well - C++ and Common Lisp - are the ones I learned from books. The rest I learned from various on-line tutorials, articles, references and sometimes from half-reading a book - and while I can code with them, I can feel my coding in them is mediocre. Hell, I feel that the generic-coding skills I have I owe mostly to books (and practice). You can't beat a book in terms of depth and undestanding.

(And don't get me started on videotutorials. This is probably the least cost-effective educational medium ever invented.)

I highly doubt there is any difference, since the only difference is the medium. If a book is published online, it's still a book.

I think you're missing the point. It's not about electronic book vs physical book (If I misunterstood you, sorry and dismiss this post). It's more about the sources on the internet, I don't know many people who read complete books on the computer but rather just read relevant sections somewhere online. While this isn't bad per se, you often miss important details due to different sources (and therefore different views/reader assumptions, ...).

They tend to be very different kinds of books. A comprehensive, deep printed textbook vs. what is essentially nothing more than a tutorial or a collection of practical recipes.

Does reading _Learn You a Haskell_ online make it any less of a book? My point is that "online sources" is a superset of "books", making them incomparable.

No. However a lot of the things I, anecdata, find when I do a google search aren't books, but blogs and random tutorials and stackoverflow.

Books, due to their published nature, tend to have a greater, more thorough, effort put into them. They are generally well laid out, usually well edited, and because people spent money on them the good ones tended to stay in the market and the bad ones tended to drop out.

There's no fundamental difference (except for me, I do much better at recalling things I read from physical books than ebooks), in the source of online versus offline. But it's hard to ignore the difference in quality that tends to happen.

What would be nice, and this is probably done somewhere, would be a reliable aggregator of good online documentation (whether it's an ebook version of a published text or not). Somewhere we can vet and see vetted quality sources of tutorials, manuals, etc.

This is among very few exceptions. Most of the books are still proper books (no matter if they're also available as e-books). Most of the stuff people use for learning online is far below a book quality.

> If a book is published online, it's still a book. reply

Not really arguing the medium of actual books (which is why I specified in my previous post). More a comparison between topic-specific books and blog posts / StackOverflow.

> more accessible and easily searchable

Have not seen more easily searchable documentation than the DEC HELP system.

> Many programmers have never bought or own a book related to programming

And it's very sad.

> - they learned from all online sources.

Did they really learn anything? Without the books? Or they are simply trained to repeat few simple tricks over and over again?

> But it's so much more convenient.

I said needless layers. They're annoyance, not convenience.

> In the old days you had to learn all about your graphics card

We had OpenGL in the old days too. Pretty much straight from the beginning of the GPUs.

> your printer,

We had hardware PostScript back then. No drivers required.

> Now everything is abstracted and easy to use

There are piles of layers well above the device drivers now. With 90% of them being totally unnecessary.

Honestly, I spend a about the same amount of time figuring out how to get the abstracted library/api/someone else's code to do what I actually need it to but it doesn't quite want to do the way I need it as I did writing it in the first place.

In the end, it's still 40 hours a week and the pay is still good :)

> We had OpenGL in the old days too. Pretty much straight from the beginning of the GPUs.

Someone missed out on the early PC days ;-) An example of what I'm thinking: Standardized-ish PC hardware (CGA, EGA, VGA, et al) might be abstracted by the programming language's libraries, but devs often reached below the abstraction, manually twiddling registers in the hardware. There weren't really standardized "drivers" for a lot of the available hardware.

OpenGL was opened in 1992, but it was only toward the late 90s that any (consumer-level) GPUs actually implemented it.

My apologies if you're mostly talking about non-consumer hardware.

> Someone missed out on the early PC days

I ignored PCs altogether. They were useless toys back then.

We had SGIs, so who cared about PCs?

> devs often reached below the abstraction, manually twiddling registers in the hardware

And we're still doing it, nothing changed. Want performance and control - go low level. Want uniform APIs - use what your vendors are trying to feed you with.

> you're mostly talking about non-consumer hardware

An SGI station is still a kind of a "consumer" hardware.

> We had SGIs, so who cared about PCs?

Who's "we"? If you mean that they existed, then OK, I can't argue that. I've never known anyone that had one, but hundreds who had PC-level hardware.

>And we're still doing it, nothing changed. Want performance and control - go low level.

Low-level has changed significantly in meaning. Now maybe someone would try to go through the driver instead of the higher-level API, but no one's going to do direct register writes. Modern hardware isn't usable at that level.

> An SGI station is still a kind of a "consumer" hardware.

Not a mainstream one by most measures, which is what I was trying to get at.

> Who's "we"?

We as an industry in general.

> Low-level has changed significantly in meaning

Not that much, actually, just shifted to the other domains.

> but no one's going to do direct register writes.

You'd be surprised. People even do bit-banging now (could you imagine bit-banging a VGA port directly in the past?).

> Modern hardware isn't usable at that level.

Is something like VC4 GPU modern enough? People do work with it on a very low level, thanks to the open specs. See this for example: https://github.com/mn416/QPULib

Actually, all the modern GPUs are getting simpler and more unifirm, so it's getting easier to hack them on a low level.

If you think those layers are unnecessary, then don't use them. Create your application using assembly and syscalls. Don't forget though, version 1 needs to be done in 3 weeks...

Good luck bypassing the unnecessary layers if your code have to run in a browser. Which is exactly an example of such an unnecessary layer (dozens of layers, actually).

And JVM is not any better.

No, the browser is a very necessary layer; it provides very effective security isolation between the internet and the windowing system.

The mainframe days assumed that software was installed by the privileged admin and that users were the threat. It's now the other way round: most computers have only one user, but need to run all sorts of software that needs to be kept isolated from the system and each other.

> No, the browser is a very necessary layer

Effective security isolation is a necessary layer. Browsers are one option to provide that, but there are others. They also provide ways to fetch, run, and interface with cross-platform, highly-efficient code from all over the world. That's both a blessing and a curse.

When I think about the volume of other people's software that we run while doing things online, I wonder how much of it is actually directly related to whatever I'm trying to do, and how much is incidental, unnecessary overhead.

Browser as it is now is a stupid and unnecessary abstraction. Even a humble Tcl interpreter running in a sandbox would have been many times better than all that thick client browsers.

This was one of the intended use-cases of rebol, IIRC. I know that code/program distribution over the network was, I believe isolation was a part of that (little time to research and confirm) or was intended to be at some stage.

Sort of interesting to think about this now, in the context of web apps and the recent Android instant apps.

I don't disagree with your arguments about how much more accessible programming is now. However I do disagree with your opening sentence:

> "Programming is so much more fun and awesome now."

Things are certainly easier, but a lot of the fun used to come from the reward of achieving something difficult. And the awesomeness would be discovering a new technique - or even simply a hack - that could optimise your routines in ways that you never previously thought possible.

That's not to say I don't still enjoy programming. But it's a very different experience: enjoyable and awesome in different ways. However on the whole, it now feels less like I'm performing magic and more like I'm building flat-pack furniture (or maybe a kit car if I'm building something a little more bare-metal and/or writing my own APIs).

Yes, programming is a lot like plumbing nowadays. It is more about connecting existing pieces, than it is about inventing new stuff.

If you are looking for more interesting things, then try scientific computing, or work on new programming languages. But don't expect to make a lot of money.

Sadly/Awesomely spot on :P

The thing that really got me into programming, and which I still enjoy about it, is being able to reason and design about code. Understanding the parts, why this happened, the patterns, connections, implications. Building up and reasoning from first principals. Its why I enjoy optimisation, algorithms, explicitly working with read-compile-run cycles and meta-programs, how data is laid out and stored and moved, and what must be mechanically/logically happening in any process.

A lot of "modern" programming seems a bit of a nightmare to me to be honest. Plugging together a bunch of poorly implemented, exception-ridden, "never really sure its working but not throwing an error yet..."

Numeric and science and performance based computing and language work...much nicer there... now if only there were some local employers wanting that and not marketing/web/mobile-apps....

I'm a mechanical engineer and I'm currently in a software job because I fell in love with Project Euler. Turns out a ton of modern software development doesn't care a whit about the algorithmic considerations PE makes you learn about. It's not very rewarding.

>But don't expect to make a lot of money.

What do you consider a lot of money?

Minecraft really demonstrated this concept well within the span of a few years.

When it first came out, it was hard to figure out how to do anything. You either just played and fiddled, or you had to dig through the Minecraft wiki to figure things out. I found this incredibly fun.

Fast forward a few years and now Minecraft is like a modern IDE. Things keep flashing up, built-in help, a guided structured tutorial.. fine, but it's nowhere near as rewarding for quizzical minds.

Does it really have a built-in help and a tutorial now? I played last just a few months ago and did not notice this at all.

I've been scripting php and python for about 10 years, and it's incredibly fun to me. It's like a lot of trial and error while trying to create a 'structure' and it's really fulfilling when it all works in the end. Even though I go to google for specific things like how to get a div in beautifulsoup, I still have to create all the logic and figure out specific things. I actually would not call myself a programmer as I've only been doing this for fun and for helping someone I know, but it certainly feels like I create more than just cut and paste or whatever, and I've also always had a feeling that I wanted the simplest solution possible and not stack endless libraries or frameworks on top of one another

CSS and HTML are frameworks though. You're not having to position elements directly to the graphics card's frame buffer; you're using markup frameworks supported by a browser rendering engine - which often depends on 3rd party code like image libraries (libpng et al) and SSL/TLS libraries (eg NSS, OpenSSL, etc. Then you have OS APIs (Win32, GTK+, etc), graphics and sound drivers, kernel ABIs, hardware firmware, etc. It's quite an extensive stack of frameworks and libraries between your code and what actually appears on screen. Even your PHP server side code depends on hundreds of inbuilt libraries to be useful, dozens 3rd party libraries (OpenSSL, MySQL drivers, etc), plus the usual OS stack.

So you're very much stacking endless libraries and frameworks on top of one another - even if a lot of this stuff happens transparently to yourself. Which is why software can be an absolute pig to debug when remote clients report subtle bugs. Sometimes it's impossible to differentiate between an "eclectic" software configuration and just plan user error.

Thanks for brilliantly putting in to words what I had trouble trying to communicate these years. I remember learning C++ as a teenager confused by boreland manuals and meaning of obscure terms like "file handle" and cryptic errors. Now all it takes in right click + inspect element to open a JS console.

This is just the beginning.

That, to me, is what made coding more fun. You _couldn't_ simply click something. You had to try and fail and try and fail.

The late 80's, early 90's were much more fun programming than today. There wasn't 20 layers of abstraction between the developer and the machine. You had to code against the metal, so to speak.

> You had to code against the metal, so to speak

These days, you can actually code the metal itself (so to speak) with easily and cheaply available FPGAs! That to me is even more exciting, certainly a lot of fun, and at least I've been doing a lot of trying and failing with it.

You can do it as a hobby, yes. But if it is your job, you'll still have to navigate your way through impenetrable piles of convoluted needless layers.

Not to mention the awful closed-source toolchains.

I think I view programming as mental abstractions in action, or to put as Steve Jobs did bicycles for the mind.

https://youtu.be/ob_GX50Za6c

One more thing that's awesome about today is that this is the first time a really wide selection of CS papers has been available. I think even six years ago, you needed a university library to effectively scan papers. Now, I can combine Google and Google-scholar and make a quick sweep of a whole variety of obscure or not-obscure theories and algorithms.

> you're able to immediately get things in the hands of your "normal" friends and see what they think.

A friend of mine teaches kids how to code. Kids get really excited when they see apps they made actually work on their own phones.

Anecdata: I am far, far, far more mentally lazy as a consequence of Google and modern toolchains than I was with EDLIN, MASM, and the Purple 8086 Book.

In terms of raw productivity, sure, I produce more. But personal satisfaction and self-esteem is far lower, and nostalgia and ennui are high.

> you can have a lot of fun right now

Can't say anything about beforehand, but I know I'm certainly having a hell of a lot of fun programming now. What a time to be alive, and I mean that!

"What a time to be a programmer."

Yes, what a time! I imagine next years, and I wonder how much still better it shall be. Great times are coming.

Reply on news.ycombinator.com