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.
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?
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.
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".
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?
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.
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!
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:
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..." "???"
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]
> 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.
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 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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
When I was 17 (about ~10 years ago) I was hospitalized for a whole month. All I had was my linux laptop without any games (well, I did have Battle for Wesnoth which was great) and no internet connection in the hospital.
I was so bored of being bed-ridden at the hospital that I eventually started browsing the source code of a C++ game engine (Irrlicht engine) and use that as documentation for a small game project. During that experience I learned to read the local documentation, read the source code and actually figure out how stuff was implemented in the engine, which quirks it had and even modify and recompile it.
Simply because I was bored and I had no way to get the answers I needed off the internet.
It was a very enlightening experience, I think every developer should get to a point, at least once in their life, where they're just sitting in front of the computer with no external distractions and no internet connection, just explore what you have and make the best out of it.
A variation on what you're describing was actually my very first experience with computers. The programs that came with my Apple IIc when I was about 8 years old weren't very interesting to me so I started poking around and playing with BASIC code.
It's kind of funny to think that at the time the sole purpose of my computer was to help me write and run programs I wrote myself.
> "I think every developer should get to a point, at least once in their life, where they're just sitting in front of the computer with no external distractions"
Well, that's why I use Emacs in full screen mode, without menu bar or tool bar, with a very minimal .emacs configuration and only reference documentation inside Emacs in info format.
Yea but I guess the point is 'self control' - I use emacs full screen too, that doesn't mean I don't just switch to a workspace for a browser when I need it.
It can be kind of a fun experience to try coding something substantive without an Internet connection - say, while riding Caltrain or on a plane flight. It's a very different workflow. You need to download all of your docs ahead of time, and then get used to browsing through them as the doc generator intended. If you get stuck, better dig into the source code of that library you don't know how to use. You end up thinking through your code a lot more, and being more careful and more rigorous about the library calls you use.
I've found it's a pretty handy skillset to have, but for most everyday programming, I'm happy to reach for the search box.
I used to commute by train regularly and used some of that time to work on a side project. One thing that helped a lot was having a local mirror of the website and documentation for key libraries I was using, which kept a good balance between having access to what I needed and not being distracted.
I've been working on a game recently, (https://technomancy.itch.io/bussard) and I've been struck with how refreshingly simple and self-contained it can be compared to a web service. I can still count all my dependencies on one hand instead of pulling in a huge intertangled graph of them, and I nearly always find that when I run into problems, they are of my own making instead of being thrust upon me by 3rd parties.
Granted I need reference documentation for the engine (love2d in my case), and I occasionally consult the Lua stdlib documentation (which I get from apt-get), but that's about it.
I've found that the most effective projects to try disconnected are often the most difficult, in terms of fundamental CS needed. You don't want to do something like a mobile app or realtime Node.js SPA, where the majority of the work is in looking up API calls and debugging why a third-party framework isn't working. That is, unless you really know the technology well...I wrote much of the code for a startup a year or so ago on Caltrain, because it was Django and was like the 4th or 5th Django app I'd written, and didn't really stretch my comfort zone much (technically, at least; the social challenges were new and difficult).
Instead, things like compilers, complex algorithms, data formats, data mining, etc. are good candidates for offline coding. Most of the knowledge for them exists in your head, and the ratio of thinking time vs. reading time is much greater. In the case of data mining & machine learning, there's also a long iterative process that involves looking at your data, coming up with insights, implementing your insights, and evaluating how well it improves the algorithm. If your test data fits on a laptop (not all interesting data does), it's a good candidate for offline development.
My first real experience with coding was the NeHe OpenGL Tutorials (which are still available online ironically). At the time I was writing a visualization plugin for an early version of Winamp, and I downloaded all NeHe's tutorials and saved them offline, as well as the OpenGL reference and Visual C++ CHM help file.
I would then go down to spend time with my grandparents in Southern Ohio, without any kind of Internet access, no cell phone back in those days, and a barely Pentium laptop. I later hauled my desktop down there, but most of the time was spent out on the deck with my shitty laptop.
It was amazing.
I would just spend the entire day coding and learning, while my grandmother read her book, out in the wilderness, looking out over a picturesque lake every now and then to clear my mind and think about a problem I was having, or to ponder the next steps in what I wanted to learn or do. Especially hard problems would require a nature walk while I thought about how to best represent things in the real world and grasped 3D graphics concepts for the first time.
In between breaks we would take turns getting up and making tea for one another, and every now and then I would make something cool, or learn something for the first time, and excitedly have to show my grandmother, who would immediately tell me I was "so smart" and shake her head in amazement of "modern technology".
Towards the end my grandfather put up speakers and we listened to old 50's and 60's big bands out on that deck during these trips. I think more than anything these were the shared experiences that got me into coding and really opened my mind up to the possibilities.
These days, this kind of situation and environment is hard to replicate. Things are just so unnecessarily complex and now all our tools expect an Internet connection to work. It makes me sad that today's generation will probably never know the kind of experience I had. There is something about not having the Internet at your fingertips that forces you to reason through things on your own and find your own powerful source of creativity rather than the route search/download someone else's code that we all do now.
While I don't live in as nice of a place as that, I used to go on walks with my dad when a programming problem was bothering me (he used to be a programmer in the 90s and early 2000s, but is a lawyer now). These days I still go on walks by myself when I'm trying to solve an especially hard problem, and my suburb is very tranquil and calm at night. Good chance to get some exercise and think about whatever is bothering you.
IMO, you don't need the internet to solve a problem if you actually understand what's going on.
That sounds so incredible. Coding purely for the enjoyment of it. Coding just for the value of the learning. Kind of the most pure way to enjoy something.
I remember spending an entire holiday at the spanish sea reading a thick Delphi 3 book... and I had a great time, especially after returning home and programming all the software I had designed in my mind.
I have been a dev for 15 years. Its seems less fun now. I did hard core C++ games for 13 of that (Nintendo DS+Wii, 360 and PS3 games). You always had a pretty good sense of what what going on. Now I am doing web/mobile. Its just a messy swamp. Everyone's first instinct is to slap another JS library on every problem. The build breaks and I ask what does somebslib.js do? No one knows or cares. They just keep slapping more JS on the problem until it looks like it works. No desire to have a clear mental model. No desire for efficiency. Oh well. Working on personal projects is the only super fun coding I get to do.
I get what you're saying, but I don't think we should stop this movement of "plug and play" coding. Last year, I needed to build a really small app to be used internally by my company. Without "slapping another JS library" in, it would have taken me 6 months to build this application, but I did it in 2 weeks. It works, ~30 people use it every day, haven't run into any problems.
A critic would say, "but what about in ten years when they need to fix a problem with the app you built, but none of the libraries are around, or have all changed significantly, etc". To which I say, just build another one, the first one took me two weeks, just spend another two weeks building a newer one. Code is cheap, throw it away and get new code if the old stuff stops working.
This attitude bums me out so much... Especially when people act like they are "delegating responsibility," when they just don't want to think about one piece of the app anymore.
You can get so many huge productivity/efficiency gains simply by having a clear sense of the whole architecture. It doesn't even have to be one person with the whole thing in their head. Even just documenting out everything at a high level in a centralized place can add a lot of value.
This sounds like more of an issue acclimating to a dynamic language from C++. Some JavaScript developers don't use any libraries at all! Not the best solution either, but you have to remember how to be independent and constructive, even if your ecology is a "messy swamp." There is just as much demand for proficient writers of solid, efficient code on the web as anywhere else. Don't believe the hype.
In the JS world, there are a lot of crutches. jQuery used to be a crutch until the modern browser evolved; npm has 110,000 free crutches. But if you can walk, run, and stand up on your own, you shouldn't need crutches and shouldn't be bothered by others using them.
And there are scant few JavaScript libraries that let you choose what to take a la carte from them. The most extreme a la carte example I can think of is Lodash, which offers to let you pull each API function it offers as a separate CommonJS require! When you can go to those lengths, you show you care for your users and deservedly beat out the competition.
JavaScript libraries need to do this more. Sure, it is important to offer the uber dependency by default for users that don't care, but the a la carte form has to be available if users like me only want to take bits and pieces.
Other than that, we had to get listings in Crash, Your Sinclair, Micro-Hobby, Micromania, Input, Spooler. Most of them we had to fix before they could run, because there were always the usual typographic errors breaking the code.
Specially painful when typing hexdumps of Assembly for entry into monitor applications.
Then those of us lucky enough to live close by to a library with computing books, also got to hold some of them. Or get to meet others to share our ideas.
When I managed to get online to the local district BBS, I was already 18 years old, and one could hardly use it, because how expensive it was and it only allowed between 5 to 10 simultaneous connections.
We were forced to think out of the box and try to figure out the solution to a given problem on our own. Which lead to very creative ideas.
Specially in the demoscene community, which was a great experience back then.
We also are expected to get everything done and working yesterday. For my hobbies I get to take my time and do it how I'd like but for work I don't get to play around.
When I started coding 30 years ago, I didn't have internet, and being a kid living in a remote rural area where even the nearest bookstore is a long drive away - virtually unreachable for a 12 year old - I hardly had any resources available at all. It was both frustrating and exciting.
Every book or tool you could get your hands on was a treasure; and my friends and I, developing primitive adventure games, had to reinvent some wheels in pretty lame ways, like image compression for our backgrounds, or drawing of sprites onto a background.
I once got my hands on a 8086 assembly manual, what a gem that was! but alas, we had no assembler or a C compiler, so we reverted to creating blank files and using DOS' DEBUG.EXE to tweak the assembly from all zeros to whatever we wanted.
It was really exciting although not very "productive". Then one of the guys got a modem and the BBS world opened up to us, and it was never the same again.
Very similar story here, and I share the amazement at my own patience, but then I remember - there was nothing else to do. I was a kid - no car, no job, 3 channels on TV. What else would you have done?
I only started programming at all because the bundle that contained the computer + tape-deck + games had a faulty tape-deck, such that my family couldn't use it.
I spent about four days reading the manual, complete with BASIC tutorial, until the shops opened again and it could be returned & exchanged.
(This would have been in 82-83 or so. When I was 7.)
Books were also so expensive! I remember using the local bookstore as a sort of Google. I would get stuck on a problem, go to the bookstore with pen and paper in hand, and copy down possible solutions.
Definitely not efficient, but the disconnectedness forced thinking about a problem rather than just searching Google.
[Obligatory Monty Python reference] Pen and paper? Luxury! We had to walk 40 miles to the bookstore, in the desert, at night, memorize the solutions, walk back, and be on time for school I tell you!
Haha, I certainly was not walking uphill both ways, and the bookstore was only about a 20 minute drive away :)
But I do think older people have a certain appreciation for the internet and the likes of Google moreso than younger people. There was a time not long ago when every piece of information was not immediately accessible in my pocket. My grandparents had an actual encyclopedia set that was treasured along with their 100s of issues of National Geographic.
Of course not everything is rainbows and butterflies today, but the world as a whole is better than what it was. People have access to opportunities that were never thought possible before. Pretty amazing really.
Maybe programming with Google by my side has taken away some of the romance I associated with programming, but it has certainly made me a better and more productive programmer.
I found a Zip drive(anybody remembers those?) with lots and lots of my early source code, circa 2004, when I programmed day and night, because it was so much fun to learn. There was no Stack Overflow back then and even Googling yielded fewer results. Unfortunately some of the creative solutions I came up with back then, make me cringe right now.
Being able to consult with knowledge and experience of people much, much smarter and wiser than me, has made me more productive. I don't waste time solving the same problems again and again, I can find tested and efficient solutions to problems quickly. I am more productive by leveraging all the knowledge. I am not paid to implement quicksort and then test it extensively to match already existing solutions that are blazing fast, I am paid to do real, practical work. The less boilerplate I have to write, the better.
I remember playing Warcraft 2 off of a Zip drive simply because my hard drive was so short of space. Taught me many lessons about data bottlenecks and optimization.
Anyone who remembers Zip drives surely remembers the jealously towards those who had Jaz drives.
My (I was 8) first computer (not PC) I got beginning of the 80s when there were only BBSs with, at least in my country, not much programming info (pirated software, images, stories, text games, porn). I had a Basic, assembly and C book second hand and I bought the occasional magazine and listed/disassambled existing software I typed over from mags or downloaded. That was all that was needed: the rest you had to make up by reading in the manual or experimentation.
For my current hobby projects I use things like C, Forth, Lua: languages and libraries I can keep in my brain and do not need internet for to write things that work. Compared to commercial work it is especially the fast changing things (often changing for no apparent reason) like JS projects and/or some web/app frameworks that really require Google. Certainly the best practice to use a library for everything, even when unstable or rapidly changing, is a pain. It is often much faster to write things yourself without having to debug yet another library but you keep thinking you are wasting time and fall for it. With internet not available you have to find a solution yourself. Using a lib is usually the better solution but just writing things without Google just feels better to me.
Lua was my first programming language and it really is beautiful in that you can keep the whole language in your head and write entire programs without looking anything up. In fact - when I first started programming in other languages, it would essentially boil down to: write snippets in Lua, then google to find out how the syntax works in the other language, and copy it over.
Yeah that is why I did (and sometimes do) in Forth. Because it's terse and no syntax it is so rapid to just try little things out. Unfortunately MOST code I write does not benefit from that (web/app) but the embedded and game work certainly does.
This is very much on-point, many of us are working with a bunch of disparate technologies loosely connected by standardised protocols and considerably less standardised APIs.
I find coding offline more constructive - my most productive coding sessions are on the train. Getting to focus on what I'm trying to achieve without getting distracted is important and useful.
But debugging is impossible without the internet, I find. Working out what an error means from just the error description and the source code of the library is bloody difficult. Googling the error message gets better results immediately. A friend and I were talking about this, that maybe we should just use UUID's for error messages and write the error description in Stack Overflow, since that's where they'll end up anyway.
> I find coding offline more constructive - my most productive coding sessions are on the train. Getting to focus on what I'm trying to achieve without getting distracted is important and useful.
I do this as well. Airplanes and underground trains are some of my favourite places to program.
> But debugging is impossible without the internet, I find. Working out what an error means from just the error description and the source code of the library is bloody difficult.
I find most bugs by reading the code.
The error doesn't mean anything.
You have decided that the computer did something unexpected. Rather than assume the computer is wrong, you need to assume that it is correct, and that some part of your assumptions were wrong.
A friend of mine was trying to hash some content, but every file it hashed was `da39a3ee5e6b4b0d3255bfef95601890afd80709` so he tried all sorts of stuff. If you know what the SHA-1 of an empty string is, then you're like google, but if you just read the code, you'd see a `||` instead of an `&&` that meant that the `read_file()` never occurred.
I think the difficulty of debugging just depends on the problem. If your problem is largely composing third-party libraries and services, then yes, it's extremely difficult to do when disconnected. But in my experience if it's mostly code you control, and you're iterating on the design and flow of the execution, then being online is mostly just a distraction.
Please consider a "horse battery correct staple" style error message, because sometimes one (say, a TA, or a friend helping a friend with a CS assignment) will receive that error message in a JPEG taken with a cell phone camera.
I think part of the problem these days is expectations.
Many years back, drawing a simple vector drawing on the screen was amazing... now it's a single command, and people expect HDR 3D rendered images otherwise it's not worth doing.
Life is busier, more 'impressive' and the internet shows you many people who are so advanced you shouldn't even bother.
The days of home computing were awesome in so many ways.
Then again, the opportunities are just different these days - the astonishing capabilities given to new games designers through Unreal Engine / Unity, etc.
The ability to show your work to so many people and not need computer 'friends' that live nearby.
It's just different.
It is a shame that so many people don't read so much to gain knowledge but instead mentally cut/paste examples to build something quickly.
I learned programming alone with qBasic when I was 14 without internet.
By luck my father had left an icon to qBasic on his win 3.1 computer and it had a similar interface to edit which I knew very well, and I opened a file and realised the code made it go.
qBasic had a good and complete help with all the functions and examples. I loved it, and It helped me learn english and basic.
I remember playing football with friends and an idea came up to solve a problem I had at the time and I stopped playing to write the code in my school notebook. When I came home, it worked.
The internet has many dogmas and principles that are being repeated and learned by novices without understanding why by going through it themselves. Sometimes a singleton is the right thing to use, for example.
Google is too useful to not use it, But you shouldn't have to do a google search because you don't remember a command or basic functionality of a language or library.
That information should be rapidly available by the documentation.
Google should be used for troubleshooting or researching a new concept.
One of the advantages of Google is that technical documentation often omits critical details. How often do you look at something on MSDN, or Apple's docs, and just scratch your head? Then, a quick Google search fills in the missing information!
Back in the 90s, I couldn't just go Google the ambiguous areas of Borland's documentation. As a result, I probably made lots of silly novice mistakes that a novice today won't make.
I have a slightly different perspective as someone who learned how to code in recent times (about 4 years ago) with the rich amount of resources on the web.
I do use Google & the internet generally a fair amount, largely for referring to APIs, but for various people's approaches to solving certain problems on occasion.
The two dangers of relying heavily on Google though is losing knowledge & sometimes generating doubt in ones conclusions from a well-reasoned understanding of the problem, and encouraging inefficiencies when sometimes a little harder thought at a problem could solve it much faster due to having sufficient knowledge.
My opinion is that there are pros and cons having the vast resources of the internet, and while it has mostly been a net positive thing, we should know to guard against the weaknesses that is possible to slip into being too heavily reliant on it.
I often find myself contemplating to move my information consumption back to a purely paper based approach as long as this is still possible. After all, good newspapers and magazines do a good job at curating the most important information for me. The fact that this way, "news" arrive with a little delay at my desk, doesn't make me less smart on a higher level. The only useful information on the net (useful in the sense: makes me money and saves time) is purely job related stuff. But the net makes it really hard to only read those parts... I still hope, I can find a good balance on the electronic world one day.
I feel that programming is fundamentally similar to other writing in that there are more and less research-oriented "subtypes" of writing and writers.
If a journalist is writing a 1-column newspaper story about how the European Central Bank's latest meeting affects banks, that's clearly a research-oriented piece. Probably she will spend more time on discovery of facts and stakeholder opinions rather than actual writing.
On the other hand, a writer working on a short story may do very little research. Fiction generally builds on life experience -- it's very hard to write a heartfelt story on a topic that you have to constantly google up.
Something similar happens in software, at least to me. There's some coding that requires constant online research and browsing... But then there's the other kind where I know my tools already, I know the project is possible based on previous experience, and I can just sit down and start writing. IDE autocompletion and one-click access to relevant API headers often ensures that I don't need online help for anything.
I like the latter kind much more. Research-oriented coding makes me feel like I'm some kind of junior API lawyer. The other kind is more like making a painting: you're slowly building up something that might be good but you also have to accept that it will look like shit at many stages. That solitary exploration is the reward to me in both painting and programming.
My problem with with trying to learn programming back in the mid-90's (my first attempt at programming) was that I couldn't find any books that I could really get into and truly learn from. I knew I should be able to figure it out, but things weren't clicking. I'm sure that had to do with the quality of bookstores in rural NH at the time, but still, it was horribly frustrating to drop a bunch of cash on a few books that seemed pretty good in the store only to get home and realize that after the first chapter or two I felt completely lost and hopeless.
Fast-forward to my second attempt to learn programming ten years later in the mid 00's, and between the sheer amount of tutorials/ebooks/other random things online, I was able to pick it up very quickly, the way I always figured I should be able to. Part of that was definitely the shift to higher abstraction levels for a lot of things, but I firmly believe a large part was that I was able to much more easily find instruction that worked for me, rather than having to choose from just a few limited options.
Because of that, I have no real fond memories of programming before google, and I owe all of my ability to the programming-with-google world. (That said, I have extremely fond memories of the communities on the BBS's I frequented back in the day!)
A bit surprised with the view of Code Googling, imho it boils down to deep and shallow knowledge. Even though results are quicker when googling you will never find optimal solutions for your problem or not even necessarily accurate.
It was a bit more painful before but the diversity of solutions was immense and solutions were optimized for the problem at hand.
It's a good thing to make programming more accessible but it's not the necessarily the way to go for all programmers.
I was one of those guys in 1990... heck I was one of those guys in 1983. But I don't really romanticize it. I still have three shelves full of books, including some classics like the 3-vol. Knuth, Abrash's Zen books, the ARM of course, as well as the C++ essentials (Lippman, Meyers, Eckel, etc.), gang of three patterns books, and quite a few others. I spent thousands on books, but I haven't bought a book on programming in something like ten years now. I once paid $140+ for an IBM manual on programming the PC VGA chip. I'm sure I still have it in a box downstairs. I also paid $700 for a 9600 baud modem, and regularly forked over $400+ a month to Compuserve, where I spent time with other geeks on the Computer Language and Dr. Dobbs' Journal forums. Interesting times.
It's worth noting that one of the reasons search is in general so important these days is there are so many more things we have to know. If you weren't actually working in those days then you don't realize how comparatively simple it was. There was more complexity on a micro scale, because we were writing compiled code w/o the benefit of all the high level abstractions available now. But on a macro level things were much, much simpler.
When I programmed in university pre-2000, I used gopher in place of google.
Applicable matches were limited to source code file search, which gave examples of function calling out in the wild. There were no books of use available, and the documentation was often vague and incomplete man pages.
This reminds me of Derek Siver's post about memorizing a programming language[0]. If I start working in a new language or new framework full time, I find it really helpful to be deliberate about learning the things I'll use regularly, to reduce the dependence on Google for common API calls etc.
Like others have said I've found that programming on a flight or long train ride is super productive, especially for starting a new feature where I'm writing fresh code (as opposed to debugging existing code). For some reason I've rarely translated that into deliberately using "flight mode" when I need to focus.
I find this interesting, as I recently completed a book (1).
My co-author (much younger and smarter than me) mentioned while we were in the middle of writing it that he'd 'never read a computer science book'.
I had to reflect on how much had changed in 15 years of software development. When I started I was using Dogpile to search for 'documents' on the 'net (which had an apostrophe then) while balancing a 'learn C++ in 21 days' book on my knee.
So 'coding without books' (and coding well) is already more than possible.
Wouldn't be a great idea a VLOG of someone coding without internet at all ,and talking about the pros and cons?
Once I moved to a small town , and I didn't have too much money for proper broadband , so I had 2 hours of dial-up every day.
I remember using that time much more efficiently and trying to download PDFs and such for the following hours , a lot of the things I've read in books/PDFs then I still remember today after 10 years. (Basic unix IPC and others)
Some of the things I've read online yesterday I don't remember today ha!
I semi-experienced this last year when I was teaching coding in prison. For obvious reasons prisoners weren't allowed to have internet access, their learning entirely depended on outdated learning manuals and tutors.
It was hard, though it became clear very quickly which books were actually written for beginners even though all of them said "introduction to blah blah" or "foo bar for beginners".
I felt like I was doing a degree in google-ing at one stage, but I don't believe the speed and complexity of development nowadays could be matched by the pre-broadband days. Communities can be brought together on sites like Stackoverflow and people who aren't experts in certain fields can just google it, and implement something in minutes that would take much much longer to find, then learn, pre-google.
With that program you even download an offline version of Stackoverflow. Just download Dash https://kapeli.com/dash and make all your coding docs offline available. It's really impressive for coding/working without Internet connection. UPDATE: Did not know about devdocs.io Seems like an opensource version of Dash.
Yeah. Dash is brilliant, though Zeal[0] is the real FOSS Dash ;)
I adore Dash though, and honestly reach for it (with a tonne of docsets loaded into it) before I reach for my browser these days. Extremely useful, especially when doing work with very well-defined APIs.
I do a lot of personal programming on public transport, and while I can tether, to be honest I prefer using Dash and keeping my computer mostly offline if I want to focus.
All the people romanticizing the good all days need to write CAD/CAM software in Fortran IV on an IBM 360 with nothing but the five thousand opaque IBM reference binders and a couple of college texts on computer graphics. To a deadline.
The real "joy" was posting a problem on the comp.lang.c and praying Dan Bernstein or Henry Spencer was online and would answer sometime in the next day or so ...
>I could focus better on the ideas and on the code. Now, with so many distractions you need to be more resistant and self disciplined.
I think it is about the task at hand. When I try drawing 2D spaceships and adding keyboard controls, it is a flowing experience no matter what tools I use.
When I start solving bugs in compression libraries or debugging million line code bases, it is all pain, frustration and google.
This reminds me of the time when I first started getting more into computers around age 13/14 and learned HTML when I had limited bandwidth dialup. I had to push myself to test things by going over to someone overs house and then tried my best to get the concepts down
> I believe that offline experience that I had in the past was a good thing. I could focus better on the ideas and on the code. Now, with so many distractions you need to be more resistant and self disciplined.
More disciplined === better programmer. The Internet is doing it right.
I got into java pre google my mac didnt have enpugh disk space for code warrior but the jdk was tiny enough to fit on my mac performa with its 250 meg hard drive. Wrote my thesis project in java 1.0 java was horrifically slow back then but the jdk was really small.
i remember back in the day when you had to order paper reference books and it took days to weeks to get them, or for the supposedly free ones you were denied because your need/qualifications were somehow not right. And you simply could not proceed without them.
A huge difference between programming Before Google and now is the explosion in libraries/frameworks/APIs. With arbitrary undocumented "features" requiring obscure setup and workarouds. Google gets you to actual programming faster.
I learned programming on a Sinclair ZX81 with the manual of that computer. I think it was called Timex in the USA. There wasn't much that could be done on that computer so the manual was more than enough. Exception: machine code, which needed another book. With two reference books I could do basically everything.
Fast forward to today. I would need a reference book for every language I use, possibly more than one per language (core language, standard libraries, etc), plus one reference for every library (jars, gems, node modules, ...). This is both inconvenient and impossible.
Inconvenient because I would need a bookshelf of, how many? one hundred books? And good luck doing it on a train.
Impossible because how could the author of Random Library XY n.0 publish a reference book for at least every major version of it? Software development would slow to a crawl (but maybe there won't be JavaScript fatigue and the like.)
The solution would be something close to what I did out of necessity in the early 90s, pre-web: download the manual of the program or of the library and maybe print it. I remember that reading a manual from the first line to the end meant that I really knew what that library did. Now it's more like I google for it, load the page, CTRL-F for the concept I'm looking for, try it, it works -> done, it doesn't work -> google more or look for another library. Shallow knowledge of hundreds of libraries vs deep knowledge of a handful of them.
Some languages enforce or facilitate writing documentation inside the code and distribute it. Example: Ruby gems usually install the rdoc so you have local documentation fore every gem you download and can use it offline. However getting to the rdoc for one among the dozens of gems I could be using in a project is slower than getting to its README on GitHub, which maybe is the only documentation there is. Can maven download the javadocs for every jar it gets? Apparently yes but I googles for it :-) [1]
Finally, looking on the ruby-lang site for that method I seldom use in the Enum class is much faster than turning pages in a book.
And this is when everything goes well. When you have errors (not the easy ones) good luck without googling the answer. You could waste days understanding what's going on. Either you end up with intimate knowledge of every piece of software you're using or you give up and find a job in another industry. Again, software development would slow down to a crawl.
So... there is no good alternative to googling with the exception of very short sessions when you want to be totally focused, you know very well every piece of software you're working on (maybe you use other software of yours as a reference) and there are no surprises.
Coding without searching basically boils down to coding without docs, and that seems pretty self-defeating.
Sure - If you just can't resist Stack Overflow's dubious charms, or find yourself updating your LinkedIn profile three times a day then cutting the hardline has some merit, but they aren't inherently programming issues.
> Coding without searching basically boils down to coding without docs, and that seems pretty self-defeating.
He does mention though, was that back in the day he used programming books, which would have contained example snippets explaining most problems.
I started coding pre-internet. All you had was your text mode IDE or editor, and if you were really lucky, it had a basic searchable help function that you just kept attacking with keywords until you stumbled on a function or principle that solved your problem.
These days, everyone goes to the top result on StackOverflow and looks at the answer, then thinks 'ok, that'll do' without actually seeing if the answer is actually the most optimal. Pre-internet, without that level of group-think, there'd be multiple ways to solve problem X, and each programmer approached it differently. Some methods would be good, and some bad, but by working it out yourself made you a better coder in the long run.
This is why I think that older programmers have better analytical brains due to their long history of not being able to 'just look it up' - you had no-one to help you; if you couldn't solve it yourself, it didn't get solved. I lost track of the many early ideas I abandoned because the routines needed were beyond my coding ability (for me, graphics coding was/is my Achilles heel). Is that a good thing or not? I don't know. But what I will say is that starting to learn to code with the internet at your fingertips, may make someone a lazy coder, but it's hard to ignore that infinite well of knowledge...
Also your compiler/libraries/OS used to come with some pretty exhaustive documentation and lots of reference books. We're talking thousands of pages here. Armed with that, and some carefully chosen 3rd party books (who can forget Norton!) you were pretty well equipped to attack programming problems of that era.
> These days, everyone goes to the top result on StackOverflow and looks at the answer, then thinks 'ok, that'll do' without actually seeing if the answer is actually the most optimal.
Maybe some people do, but I don't know anyone good who does that. They might go to Stack Overflow to get an idea of what direction they should be heading in, but they'll then use that information to build a solution that fits the overall system they're working on.
> Sure - If you just can't resist Stack Overflow's dubious charms
I rarely find useful material on StackOverflow when the problem isn't learn to do X with technology Y quickly (although there are a few very nice canonical-answers which I have book-marked for reference). I don't think a lot engineering time is spent in that though..
For me the most useful part of StackOverflow is exactly the cut and dry answers for quickly doing X with technology Y.
When designing and implementing complex systems, this allows me to cut down the time it takes to remember certain things (like how do I left pad a string with enough spaces to make it align nicely) and keep my focus on the greater whole.
Well, I sad "quality" software. There is no quality whatsoever in the web frontend, unfortunately. Piles upon piles of an overengineered convoluted mess, but no "quality" code which can be even distantly compared to the glorious libraries of the past.
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.