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.
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.
Isn't that just part of 'being a professional' tho?
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.
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.
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. :)
>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.
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.
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.
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.
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.
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.
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.
Find good libraries and mash it up to your heart's content!
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.
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.
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:
.. good luck using that professionally though, unless you get paid for creating interactive art.
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..." "???"
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?
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.
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...
Who said we stayed sane?
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.
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.
Also, if 99.9% of all those "web frameworks" just die without a trace, the world will become a much better place anyway.
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.
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.
(And don't get me started on videotutorials. This is probably the least cost-effective educational medium ever invented.)
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.
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.
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.
In the end, it's still 40 hours a week and the pay is still good :)
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.
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.
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.
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.
And JVM is not any better.
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.
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.
Sort of interesting to think about this now, in the context of web apps and the recent Android instant apps.
> "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).
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.
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....
What do you consider a lot of money?
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.
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.
This is just the beginning.
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.
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.
Not to mention the awful closed-source toolchains.
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.
In terms of raw productivity, sure, I produce more. But personal satisfaction and self-esteem is far lower, and nostalgia and ennui are high.
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!
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.