12 ms·

Whatever happened to programming?

157 points by skorks 17y ago

tjpick 17y ago
the current trend of plugging together frameworks and libraries does lead to some pretty boring, frustrating work. And the unfortunate thing is that in many cases they don't even reduce the complexity of the solution. (They certainly don't simplify the /problem/) There's a fascination with shiny new things and it's tempting to think that the latest and greatest download from some smart guy solves the problem you are solving. But after a couple years working in that manner I'm not so sure. I think it's tempting to view frameworks and/or libraries as an implementation of software patterns, and also as a way to avoid learning your trade. That's probably not concious thought behind it, but you see it in so many things... if you just learn this framework or use this library, you won't have to learn html, or css, or sockets, or synchronisation, or searching and sorting, or...
rickmode 17y ago
What happened is the we finally hit "the dream" of building software out of large building blocks instead of having to reinvent screws and bolts for every project. The lack of fun is, in my opinion, a side effect of using weak languages that force us to write boilerplate and ceremony along with using half-baked non-Turning complete XML languages (don't forget the "L" in "XML" stands for "language").
- sparky 17y ago
  "screws and bolts... non-Turning (sic) complete" Pun intended?
  - arethuza 17y ago
    I suspect he meant Spring anyway.
  - rickmode 17y ago
    Heh... Pun not intended; just typing too fast.
marshallp 17y ago
Cool stuff isn't operating systems and compilers, cool stuff is getting your computer to do your job for you. Why don't you use the knowledge you gained of prolog and lisp and metaprogram the tasks you're given to get your work done even faster. This talk about crud is boring, libraries are boring, is almost ludicrous. There are 200 million jobs in the united states alone that can be automated by software. Try to automate those jobs - that's cool and lucrative stuff.
- bugs 17y ago
  Grabbing libraries isn't fun when you first start out programming you really don't learn much and really can't do anything and I think that seems to be where everything is headed. If you are programming for work sure its going to be easier to grab a library to do a certain task for you even if you have to mangle your task a little bit to use it but when you are learning or even when you are programming for fun that is dull and really really not fun.
  - barrkel 17y ago
    I think part of the problem is having too many options. When all you had was moveto and lineto, simple programs with simple graphics was enough. Now, such programs seem so lame and pale in comparison to the state of the art, while the amount you need to know and learn to match that standard is daunting, there must be a cost in terms of programmers lost to the profession at an early age.
- sjs 17y ago
  Well, I think systems and languages are pretty cool. Knowing how they work is good practice even if it only demystifies them for you. Also, every program is either an interpreter or a compiler if you squint just right.
pw0ncakes 17y ago
Javaschools, PHBs, and other failed attempts at the commoditization/regularization of the software engineer brought this about. There are as many interesting problems today as there were in 1960 or 1985 or 1998. There will be demand for new languages (and new compilers for those languages). Operating systems may or may not be "solved" for now, but VMs are going to be of interest in the next 10 years. The problem is that, outside of high-risk startups and possibly academia, it's very rare to get permission, resources, and support to attack the interesting problems. Blue-sky research is gone. This is because of the next-quarter mentality; there's a significant likelihood of failure if you're doing something interesting, and interesting projects cannot easily be done to deadline. And everyone wants to be on those projects. So a first-year programmer at an average company is not very likely to get to do an AI research project that may or may not lead to anything. "Gluing" projects, on the other hand, can usually be completed in a predictable amount of time and have a high likelihood of achieving success for sufficiently mediocre definitions of "success".
- houseabsolute 17y ago
  > Javaschools, PHBs, and other failed attempts at the commoditization/regularization of the software engineer brought this about. Personally I am glad the same thing happened to other industries like shoemakers and car builders. They have been commoditized: so what? It's good for people who buy their product. The same is true of typical software engineering work. Although I disagree about the extent to which our work has been commoditized. I don't think we're anything like factory workers yet, although it may someday come to that.
  - gamble 17y ago
    The problem with the software industry is that it isn't productized. Probably the majority of programmers are working for internal corporate IT departments cranking out CRUD apps because the company mistakenly believes it's a precious, unique snowflake that couldn't possibly make do with off-the-shelf software for routine business processes, even though they derive no competitive advantage from custom software. Most of these jobs simply shouldn't exist. The larger problem is that too many people profit from the dysfunctions of the software industry. From the empire-building CIO to the outsourcer in India, there are plenty of people who benefit from shovelling bad programmers at bad software, and would lose out if companies bought cheap, standardized software from independent companies.
zackham 17y ago
Everyone is tainted by their own experience, I suppose, but I feel like I get to work on plenty of interesting problems. What bothers me (and this author it seems) is having to spend your time learning arbitrary things, such as an XML format for a configuration file, or nuances of how different browsers handle different conditions. However, we (web developers at least) are writing software that is supposed to run on just about any hardware / OS / browser combination, and making that happen and doing complex and interesting things in that context is going to involve lots of arbitrary details. That being said, if I think back 10 years, this type of work has become dramatically more pleasant thanks to a lot of open source software that has matured in that time. If the complaint is that we can't all write our own virtual memory system or our own b-tree, I suppose I can't disagree that that is becoming less of a reality. However, solving interesting problems still requires an understanding of these things, and using existing libraries in my experience saves me time and allows me to have a bigger-picture view and solve larger problems. It is still very satisfying. If this article is written from the perspective of someone automating simple and mundane business processes, putting together forms, etc, then I believe the complaints are misdirected.
wowus 17y ago
I weep for the software industry. Our lives are going to suck in 10 years.
- pw0ncakes 17y ago
  I'm pretty sure this complaint has existed as long as there have been programmers. If you want to program as they did in 1985, go work for a game company. Or find an investment bank looking for C++ developers; they're out there.
  - gte910h 17y ago
    Last I checked, BOA in ATL couldn't find enough super good math/finance/C++ programmers, for instance.
    - btilly 17y ago
      Of course to do that you have to live in ATL. And work for BOA. Those were two excellent reasons that I had no interest when their recruiter came calling to ask if I was interested in applying to work there.
      - pw0ncakes 17y ago
        And write C++.
    - jrockway 17y ago
      It's because the people that are good with math, finance, and programming don't want to use C++ (or live in Atlanta). Remove the C++, and it becomes much easier to find people. Look at how successful companies like Jane Street Capital are in recruiting, for example, even though the pool of people that know OCaml is much smaller than the pool of people that know C++. (My experience with people that know math and finance is that they do all their work in Excel. That's because simple programs become 100-file boilerplate monsters in C++ and Java, and someone told them that Perl and Python are not real programming languages. Sigh. OTOH, turning spreadsheets into production software is profitable and enjoyable. Let the programmers program and let the finance people do finance.)
zokier 17y ago
Internet happened. Internet has made sharing code extremely easy, and promotes code reuse which has led to current situation. On the other hand, nobody is forcing you to follow this "glue libraries together" -method. Disconnect from the internet and just start coding. As a bonus you'll get rid of a lot of distractions (email/IM/twitter/whateva). It can be quite refreshing, and who knows, maybe you'll even create something new and awesome.
eplanit 17y ago
The author captures the sentiments of a generation of programmers quite well. In the 80s, at the beginning of my 'professional' programming career, I wanted to not believe those who foresaw our careers as being like engine and automotive engineers of the early 20th century. That is, destined to become "parts changers". Early-phase technology workers with those sophisticated machines were true 'engineers', and were paid well. Over time, things evolved (of course). That history confirmed and taught that as technology matures, it becomes commodity. Economies of scale emerge, markets develop, etc. make it such that the technology practitioners ultimately become installers and configure-ers. I think it started to go awry, in my timeline, when the term Application Programming Interface (API) hit the streets. :-) However, the above is really only true in the 'application development' space. Most software development opportunities are in that space; and therefore, yes, most opportunities to develop software are boring, non-engineering jobs -- rather blue-collar, in fact. To one steeped in a true CS background, that's a real disappointment when considering a lifetime career. This is true for those in their 20s as well as their 40s. So, I agree with other posters here: get creative! Reject the direction of the herd, if it seems fitting. Do it anyway, just to experience and learn.
- deleted 17y ago
  [deleted]
sgacka 17y ago
Libraries were created so that you could focus on mastering new and unexplored territory, not to replace programmers. As a beginner, I didn't appreciate big libraries (like Cocoa). I couldn't wrap my head around the idea of having tons of prewritten code and stitching it together - I understood programming as writing code - so I wanted to write my own damn code, not just manipulate massive libraries. So I turned to PHP and developed my own webapp (a stripped down Google Docs), from scratch. I quickly stumbled upon the purpose of frameworks and libraries. After writing my 20th SQL query I realized I was wasting time. About 10 hours later, I made my own light PHP framework. Now I didn't have to worry about my SQL syntax (it was automated based on the data model variables) and I got to start working on really cool/interesting programming issues rather than the mundane blah code. Now I've started to investigate Cocoa again and I realize that libraries and frameworks have not hurt programming, but dramatically catapulted it into the realm of science rather than plug-and-chug. Today, our software is more complex than ever and it will only get more complex in the future. I think if you see programming as just "stitching libraries together", then you've lost your passion or never had any to begin with. Programming has evolved into a science where you have to learn the foundations (languages) AND the pre-existing solutions (libraries) in order to figure out what's been done for you so that you can focus on exploring new and more complex issues.
- marshallp 17y ago
  I think you need to really learn what sql is. It's a 4th generation language, higher level than php or other oo/procedural/functional langauges. If you're finding php and a framework to be better you're underestimating the power of sql.
  - zackham 17y ago
    What about the very common cases where you need to do very simple things, like common CRUD operations? Abstracting the SQL required for these simple queries makes a lot of sense to me.
    - marshallp 17y ago
scorciapino 17y ago
"For me, there is a sort of metallic flavour to most raw tuna;" - yes, it is called Mercury
- gamble 17y ago
  If you can taste the mercury, you're in trouble.
  - scorciapino 17y ago
    That was the point! :)
albemuth 17y ago
I've been feeling like this lately, every now and then there are some interesting problems to solve but more often than not it's all just plumbing...
- drgath 17y ago
  Every now and again? What?! If you can't find problems with today's internet technology, you aren't looking hard enough.
gamble 17y ago
The problem is not that libraries exist, but the incredible mental investment required to use them. Early libraries were just bundles of functions, but modern libraries are vast, complicated beasts that require years of experience to fully grok. But don't take too long, because they all exist in a state of perpetual churn, and hitching yourself to the wrong train could well destroy your career.
patio11 17y ago
Is this an indictment of frameworks or merely an indictment of bad frameworks? I've worked with both. Trying to manhandle JAX-RS into marshalling your objects in exactly the right fashion such that the XML parser doesn't barf on them is not exactly uplifting work... but it did get something done for my customer. Working with well-designed frameworks, though, is a true joy. It means I spend a minimum of time on plumbing and spend the majority of my efforts solving problems for my customers or otherwise doing high-value work. I understand there are folks out there who love socket programming, but I've done socket programming, and I have no desire to ever touch it again. Good HTTP clients, REST, etc make that totally unnecessary for the types of problems I routinely have to solve. (Speaking of good frameworks versus bad frameworks -- even in Big Freaking Enterprise Java there is a titanic gulf between ways to implement web services. RestEasy is probably the best architechted framework I've ever seen -- it is so good you can forget you're using a web service at all.) My next business will need to make telephone calls. There is a whole lot of very ugly coding necessary to make that happen. Happily, Twilio has apparently already done it for me. I'll just snap together Twilio and Rails to be able to make the customers' phone ring, and concentrate on delivering the smart part of the service, which is that making sure what happens after the phone rings solves a real problem that is preventing their business from making money.
- ajross 17y ago
  I think it's more an ode to "plumbing". From your tone, I get that you don't see much value in or get much enjoyment from writing a parser, or doing pixel-level image manipulation, or writing extensions to your editor to gete it set up just perfectly, or trying to get your code to fit in a 64k segment, or debugging hardware drivers. But some of us do. We're just different. For you, and most modern programmers, there isn't much value in that stuff, and you don't want to have to do it. And, in the modern world, the truth is we don't have to except in the rarest of circumstances. In the modern world, developers (they aren't called "programmers" anymore, it seems) have the freedom to worry about prioritizing "high value work" to solve their customers' problems. But it wasn't always that way. For some of us, that kind of sucks.
jdietrich 17y ago
My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like. Don't get me wrong, I'm grateful for all of it, but it just doesn't seem like what I was promised when I followed SICP for the first time. It just feels like I spend most of my time scouring through documentation and trying to remember umpteen different sets of syntax and class names rather than actually thinking in code. Back in ye olden days, most programming tasks I performed felt quite natural and painless, just a quiet little chat between me and the compiler. Sometimes longwinded, sometimes repetitive, but I just sat and though and typed and software happened. The work I do these days feels more like being a dogsbody at the tower of babel. I just don't seem to feel fluent in anything much any more. We talk about 'flow' quite a lot in software and I just have to wonder what's happening to us all in that respect. Just like a conversation becomes stilted if the speakers keep having to refer to their phrasebooks and dictionaries, I wonder how much longer it will be possible to retain any sort of flowful state when writing software. Might the idea of mastery disappear forever under a constant torrent of new tools and technologies?
- alanthonyc 17y ago
  I know exactly how you feel. Having to pick up all those different knowledge sets is something else. However, I balance the fundamental desire to build things against a fundamental desire to build things people can use. It's the pride in me. The closest I came to it a long time ago was when I animated a bunch of search algorithms for a class project in college. That was one of my favorites because I could show my non-geek friends what I was doing and they could appreciate it. It's a big reason why I am now focusing on my web app. The web is at a point where I can build something and get (potentially) millions of people using it. I'll sacrifice some hands-off-ness in my programming for that.
- jimbokun 17y ago
  I kind of like it. The thing is, most of the languages you mention are pretty good at what they do. Python is a good general purpose language, and Django is just a Python framework, right? (Not a Django developer.) XHTML does a good job describing hierarchical content to be displayed. CSS is a good language for styling content separately from the structure on a site wide basis. JQuery and Javascript can be looked at as a single thing, and if you know the syntax for Javascript data structure literals, you pretty much know JSON. Google App Engine seems to potentially offer a lot for the learning curve required (not an App Engine developer, just read some tutorials). XML, well, there's just no excuse for that. :) Some people complain about all the parts you need to know to build web applications as compared to desktop applications. But I think that the different languages each doing their thing well makes for a better development experience. The other great thing is the diversity of choices for the backend technology stack, like Viaweb deciding to build web apps just so they could avoid Windows and use Lisp (...and some Perl and C++, I think).
brown9-2 17y ago
I want to make things, not just glue things together. When people ask me what I like about my job, I always say the same thing: that its the thrill of starting with nothing and making something. I couldn't agree with this more.
msluyter 17y ago
Yep. I've been going and digging up old ACM and other programming contest problems just so that I don't forget how to actually code something from (near) scratch. I was disturbed to discover how rusty I was.
- ern 17y ago
  I started doing Project Euler problems for the same reason last year. I even sat up with friends one night working on a few problems, just to recapture that college feeling. But I know writing algorithmically interesting problems are not likely to appear at work, and I've made my peace with that, along with the paycheck I get for writing enterprise systems.
kylemathews 17y ago
My comment I left on the post: I guess it depends on your motivation. I don't program because I love creating complex data structures or innovative new algorithms, I program because I want to create innovative new applications that change how people live, think, work, learn, etc. I signed up for programming so I could change the world for the better in my own little way -- not improve how an electronic machine inputs and outputs binary input. But to each their own. It seems everyone likes to work at different levels of abstractions. I think we can both agree that those electric engineers are weird :)
jimbokun 17y ago
I think to do actual "programming" you need to work for a software company. Google and Facebook and other gargantuan sites have as much interesting CS stuff to work on as you could want. I'm sure many at Apple and Microsoft still get down and dirty with OS internals. There are a lot of companies springing up focused on machine learning over massive datasets. If you are building applications for end users, though, it's hard to justify not leveraging libraries and frameworks that already supply much of what your users want. Especially if the software does not directly make money for your organization.
andywood 17y ago
Wow. I sympathize with this very, very strongly. I think this captures the root of the career frustration that I experience 70% of the time. I seem to spend way too much time on what I call "guessing the magic password" - tracking down that one bit of punctuation in some obscure value in some xml configuration file that makes my whole system fail silently in one environment. I might spend 5 hours beating my head against a wall, only to finally figure out that this brittle system over here needed me to put some proprietary prefix on some host name in this one context. And at the end of it, I don't feel accomplished. I feel like I'm wasting my life! Figuring out which parameters to pass to which APIs in what order is a step above "guessing the magic password" - but it's not that big a step. A few things come to mind. You can try to make sure you are one of the people writing the libraries. You can implement the next platform and use all the aesthetic sense you have in you to try to make it a joy for others to use. Put yourself in the position of the programmers who write the systems that make the rest of us age faster, and try to do a better job. Or content yourself with getting your programming joy from your elegant side-projects.
- DanielBMarkham 17y ago
  I seem to spend way too much time on what I call "guessing the magic password" It's always been this way, but lately it's gotten worse and worse. You need to fix a problem. Your friends tell you about technology X which seems exactly what you need. So you pick it up, take a quick look at the samples, and wham! Within minutes the thing is working exactly like it is supposed to! Well almost. There's this little part that's broken that ruins the whole thing and then you spend hours or days (yes, perhaps weeks) digging up obscure configuration documentation and tweaking APIs in ancient Klingon, sacrificing turtles to Ba'al or whatever else it takes to get the damn thing working like it's supposed to. Then it's on to something new. The funny part of this whole story is -- when your friends ask you about how programming in X was, you are more than likely to brag about how easy it was to solve your problem. After all, the bulk of the problem was fixed almost instantly. Don't want to look like a dweeb. And so the cycle of pain continues.
bcowcher 17y ago
I think the core of the problem that the OP is experiencing is that most API's are really bad. By bad, I mean the API gets in your face and becomes more hindrance than help. I say, choose your API's wisely, find what helps you and discard the rest.
oconnore 17y ago
GCC?! Real programmers use punch cards. More seriously, abstraction is not the issue. The issue is poorly written libraries and languages that require you to worry about the small details. Your brain can handle many small details or a few big ones, but not both. I recommend picking the latter, and using libraries and languages that allow you to do so. Hint: Lisp is really pretty swell.
- jrockway 17y ago
  Lisp has libraries?
signa11 17y ago
This is the promised land. Remember hearing how good code re-use is? Now it's here.
- joss82 17y ago
  Hurray! Now we can focus on what's really making our application different. And it turns out to be boring. Maybe we should be more creative in our application's core functionalities, should we not?
cubicle67 17y ago
This has happened to many industries, not just programming A Pharmacist (not sure what you call them in the US) spends years at Uni learning all about drug manufacture, how the body works etc, and now all they do is type script in the computer and hand over bottles of tablets What does a signwriter do now? It used to be a skilled craft, now all it requires is typing text in a computer that then cuts the letters from a roll of vinyl sheet Or Carpentry or any number of other trades?
jrockway 17y ago
Programming for the sake of programming and programming to solve real-world problems are two different things. The first is more fun, the second is more profitable. Since most people want money rather than fun, most programming is of the second type. If you want to program something fun, nothing is stopping you. Thanks to the libraries, you can concentrate on what interests you, rather than the details of how some standards committee thinks the word "referrer" is spelled.
- logicalmind 17y ago
  I think your comment hits the nail on the head. I've worked with web apps for a long time and I quickly learned that all I was doing was writing software for some business process. This isn't the sexiest work or the most interesting, but it has never stopped me from doing interesting things. For example, I try constantly make less work for myself. So much of the code we write is boilerplate so I have various tools that generate as much code as possible. I have written mini languages that specify the important parts and then generate all of the plumbing around it. I won't run out of interesting problems until I can generate an application by specifying the important parts (to the business) and generating everything.
sshumaker 17y ago
The whole point of libraries and higher level languages is that they allow you to work at a higher level of abstraction. As the languages and libraries improve, difficult problems become trivial, while impossible problems become merely difficult. Given enough time, problems eventually become trivial enough to be solved by non-programmers. There will always be a frontier - problems that have barely just become solvable thanks to improvements and technology, and these 'very difficult' problems will be what the best and brightest will be drawn to. Maybe the author is working on problems that aren't challenging enough.
- rw140 17y ago
  I'd take the view that the emphasis has shifted from 'can we do this? / is it possible' to 'how shall we do this? / what will make our users happiest'. Both of these are great aims, but the former is probably more fun. There will still be edges where the emphasis is still on 'is it possible' but as the technology matures, you'll probably have to seek them out, rather than be there automatically.
samratjp 17y ago
It's a pity that so many friends of mine gave up programming after starting out with Java... But, at least MIT didn't ditch Scheme for Java @intro level. Better Python than Java any day :-)
wedesoft 17y ago
This was maybe the main reason why I switched to Ruby. The largest part of my time was spent on integrating other people's work. Don't get me wrong. It would take me more time to write the code from scratch and it would have introduced redundancy. But it just didn't feel right spending so much time on getting other people's stuff play together. I think the problem is that C/C++ and Java don't scale semantically.
nhoj 17y ago
It seems the author of the article is stuck in a problemscape where all the problems he would find interesting are already solved. One solution is to move to a new area of software development that offers challenging problems. I am currently, like many others it seems, working with creating enterprise CRUD-apps and integrating them. I try to find joy in reaching for a skill level where I can produce solutions quickly, solutions that are easy to change, solutions that immediately lets you know where and why an error has occurred, solutions that are secure, solutions that scale, solutions ran in the cloud instead of on servers that it takes it operations months to set up etc. There really aren't that many people out there that can do all of the above well (me included) and there are lots of money to be saved for your employee/clients doing those things well. I think we would see a lot less attempts at off-shoring if more people in enterprise-it would strive for that kind of knowledge. I guess what I'm trying to say is, maybe one shouldn't have too high expectations of the technical challenges in problemscapes that have been mostly solved already but that, at least in my area, there are still challenges to be found. They are just of another kind and maybe you can find them interesting? They keep me interested enough at least. sigh Why am I posting on hacker news again?
motters 17y ago
If you're just plugging libraries together it's a sign that the area of computing in which you're working has ceased to innovate.
nazgulnarsil 17y ago
boo hoo, the wild west days of roll your own everything are gone. except they aren't, you just have to be good enough that companies working on the forefront of non-standard (yet) hardware will hire you.
lurkerperpetual 17y ago
There is fun and exciting work to be done still. The fact that most of us chose to work on boring plumbing has little to do with programming having changed; it became a more diverse field a majority of which is 'commoditized'. So why complain? Go do something interesting. If the problems you are solving as your daily routine are themselves boring why would the process of solving them be any more fun?
ndl 17y ago
Years of research and countless dollars have gone into making programming a systematic, controllable process. Old school managers frequently wish that a dev team would output like an assembly line. Simultaneously, we're expected to be into the newest and coolest technologies. Put these together, and we're supposed to systematically glue everything that's new. Seriously, it's not all bad, though. I like being able to generate a test UI in under an hour or a basic web spider in one python file. The art's just different. It's no longer packing your entire logic into beautiful lines of BASIC. It's now more about choosing the right platform to do something that the user will appreciate. If you're into the pre-library styles, I recommend looking at alternative hardware. When I wrote my first CUDA project, I had to figure out how to get random numbers with sufficient randomness for our physics simulation. You might also look at robots or embedded devices. There's plenty to tinker with on devices that don't have libraries available.
blogdog 17y ago
A very interesting observation.. I tend to agree that the sheer number of frameworks and libraries makes programming into coping with flaws or badly documented "features". The other thing is that the programming world is much like an archipelago, where different islands develop their own programming culture, like .NET or JEE or PHP. And the islands are floating apart: It will become increasingly difficult to establish the better choice because of long learning curves. It is important to admit there are other cultures out there, that even might do a better job in particular areas. However, as much as frameworks get more sophisticated and cater to the programmers ideal of elegant and abstract formulation of the code, Managed Code, Reflection and even OO have a overhead cost in cycles and bytes, particularly when scaling up. As a 45+ programmer I sometimes weep about "elegant" code that drives your machine to the edge but only does a fairly simple job. Stacking API's and frameworks does certainly not always contribute to efficient and simple executables. Sometimes we just need to get back to the root, or at least understand what happens in the machine when we use a certain framework or library. For programmers that will remain a challenge, and fortunately will force us to reflect occasionally...
Kalibus 17y ago
It's just one of those things

157 points by skorks 17y ago

the current trend of plugging together frameworks and libraries does lead to some pretty boring, frustrating work. And the unfortunate thing is that in many cases they don't even reduce the complexity of the solution. (They certainly don't simplify the /problem/) There's a fascination with shiny new things and it's tempting to think that the latest and greatest download from some smart guy solves the problem you are solving. But after a couple years working in that manner I'm not so sure. I think it's tempting to view frameworks and/or libraries as an implementation of software patterns, and also as a way to avoid learning your trade. That's probably not concious thought behind it, but you see it in so many things... if you just learn this framework or use this library, you won't have to learn html, or css, or sockets, or synchronisation, or searching and sorting, or...

rickmode 17y ago

What happened is the we finally hit "the dream" of building software out of large building blocks instead of having to reinvent screws and bolts for every project. The lack of fun is, in my opinion, a side effect of using weak languages that force us to write boilerplate and ceremony along with using half-baked non-Turning complete XML languages (don't forget the "L" in "XML" stands for "language").

sparky 17y ago
"screws and bolts... non-Turning (sic) complete" Pun intended?
- arethuza 17y ago
  I suspect he meant Spring anyway.
- rickmode 17y ago
  Heh... Pun not intended; just typing too fast.

marshallp 17y ago

Cool stuff isn't operating systems and compilers, cool stuff is getting your computer to do your job for you. Why don't you use the knowledge you gained of prolog and lisp and metaprogram the tasks you're given to get your work done even faster. This talk about crud is boring, libraries are boring, is almost ludicrous. There are 200 million jobs in the united states alone that can be automated by software. Try to automate those jobs - that's cool and lucrative stuff.

bugs 17y ago
Grabbing libraries isn't fun when you first start out programming you really don't learn much and really can't do anything and I think that seems to be where everything is headed. If you are programming for work sure its going to be easier to grab a library to do a certain task for you even if you have to mangle your task a little bit to use it but when you are learning or even when you are programming for fun that is dull and really really not fun.
- barrkel 17y ago
  I think part of the problem is having too many options. When all you had was moveto and lineto, simple programs with simple graphics was enough. Now, such programs seem so lame and pale in comparison to the state of the art, while the amount you need to know and learn to match that standard is daunting, there must be a cost in terms of programmers lost to the profession at an early age.
sjs 17y ago
Well, I think systems and languages are pretty cool. Knowing how they work is good practice even if it only demystifies them for you. Also, every program is either an interpreter or a compiler if you squint just right.

pw0ncakes 17y ago

Javaschools, PHBs, and other failed attempts at the commoditization/regularization of the software engineer brought this about. There are as many interesting problems today as there were in 1960 or 1985 or 1998. There will be demand for new languages (and new compilers for those languages). Operating systems may or may not be "solved" for now, but VMs are going to be of interest in the next 10 years. The problem is that, outside of high-risk startups and possibly academia, it's very rare to get permission, resources, and support to attack the interesting problems. Blue-sky research is gone. This is because of the next-quarter mentality; there's a significant likelihood of failure if you're doing something interesting, and interesting projects cannot easily be done to deadline. And everyone wants to be on those projects. So a first-year programmer at an average company is not very likely to get to do an AI research project that may or may not lead to anything. "Gluing" projects, on the other hand, can usually be completed in a predictable amount of time and have a high likelihood of achieving success for sufficiently mediocre definitions of "success".

houseabsolute 17y ago
> Javaschools, PHBs, and other failed attempts at the commoditization/regularization of the software engineer brought this about. Personally I am glad the same thing happened to other industries like shoemakers and car builders. They have been commoditized: so what? It's good for people who buy their product. The same is true of typical software engineering work. Although I disagree about the extent to which our work has been commoditized. I don't think we're anything like factory workers yet, although it may someday come to that.
- gamble 17y ago
  The problem with the software industry is that it isn't productized. Probably the majority of programmers are working for internal corporate IT departments cranking out CRUD apps because the company mistakenly believes it's a precious, unique snowflake that couldn't possibly make do with off-the-shelf software for routine business processes, even though they derive no competitive advantage from custom software. Most of these jobs simply shouldn't exist. The larger problem is that too many people profit from the dysfunctions of the software industry. From the empire-building CIO to the outsourcer in India, there are plenty of people who benefit from shovelling bad programmers at bad software, and would lose out if companies bought cheap, standardized software from independent companies.

zackham 17y ago

Everyone is tainted by their own experience, I suppose, but I feel like I get to work on plenty of interesting problems. What bothers me (and this author it seems) is having to spend your time learning arbitrary things, such as an XML format for a configuration file, or nuances of how different browsers handle different conditions. However, we (web developers at least) are writing software that is supposed to run on just about any hardware / OS / browser combination, and making that happen and doing complex and interesting things in that context is going to involve lots of arbitrary details. That being said, if I think back 10 years, this type of work has become dramatically more pleasant thanks to a lot of open source software that has matured in that time. If the complaint is that we can't all write our own virtual memory system or our own b-tree, I suppose I can't disagree that that is becoming less of a reality. However, solving interesting problems still requires an understanding of these things, and using existing libraries in my experience saves me time and allows me to have a bigger-picture view and solve larger problems. It is still very satisfying. If this article is written from the perspective of someone automating simple and mundane business processes, putting together forms, etc, then I believe the complaints are misdirected.

wowus 17y ago

I weep for the software industry. Our lives are going to suck in 10 years.

pw0ncakes 17y ago
I'm pretty sure this complaint has existed as long as there have been programmers. If you want to program as they did in 1985, go work for a game company. Or find an investment bank looking for C++ developers; they're out there.
- gte910h 17y ago
  Last I checked, BOA in ATL couldn't find enough super good math/finance/C++ programmers, for instance.
  - btilly 17y ago
    Of course to do that you have to live in ATL. And work for BOA. Those were two excellent reasons that I had no interest when their recruiter came calling to ask if I was interested in applying to work there.
    - pw0ncakes 17y ago
      And write C++.
  - jrockway 17y ago
    It's because the people that are good with math, finance, and programming don't want to use C++ (or live in Atlanta). Remove the C++, and it becomes much easier to find people. Look at how successful companies like Jane Street Capital are in recruiting, for example, even though the pool of people that know OCaml is much smaller than the pool of people that know C++. (My experience with people that know math and finance is that they do all their work in Excel. That's because simple programs become 100-file boilerplate monsters in C++ and Java, and someone told them that Perl and Python are not real programming languages. Sigh. OTOH, turning spreadsheets into production software is profitable and enjoyable. Let the programmers program and let the finance people do finance.)

zokier 17y ago

Internet happened. Internet has made sharing code extremely easy, and promotes code reuse which has led to current situation. On the other hand, nobody is forcing you to follow this "glue libraries together" -method. Disconnect from the internet and just start coding. As a bonus you'll get rid of a lot of distractions (email/IM/twitter/whateva). It can be quite refreshing, and who knows, maybe you'll even create something new and awesome.

eplanit 17y ago

The author captures the sentiments of a generation of programmers quite well. In the 80s, at the beginning of my 'professional' programming career, I wanted to not believe those who foresaw our careers as being like engine and automotive engineers of the early 20th century. That is, destined to become "parts changers". Early-phase technology workers with those sophisticated machines were true 'engineers', and were paid well. Over time, things evolved (of course). That history confirmed and taught that as technology matures, it becomes commodity. Economies of scale emerge, markets develop, etc. make it such that the technology practitioners ultimately become installers and configure-ers. I think it started to go awry, in my timeline, when the term Application Programming Interface (API) hit the streets. :-) However, the above is really only true in the 'application development' space. Most software development opportunities are in that space; and therefore, yes, most opportunities to develop software are boring, non-engineering jobs -- rather blue-collar, in fact. To one steeped in a true CS background, that's a real disappointment when considering a lifetime career. This is true for those in their 20s as well as their 40s. So, I agree with other posters here: get creative! Reject the direction of the herd, if it seems fitting. Do it anyway, just to experience and learn.

deleted 17y ago
[deleted]

sgacka 17y ago

Libraries were created so that you could focus on mastering new and unexplored territory, not to replace programmers. As a beginner, I didn't appreciate big libraries (like Cocoa). I couldn't wrap my head around the idea of having tons of prewritten code and stitching it together - I understood programming as writing code - so I wanted to write my own damn code, not just manipulate massive libraries. So I turned to PHP and developed my own webapp (a stripped down Google Docs), from scratch. I quickly stumbled upon the purpose of frameworks and libraries. After writing my 20th SQL query I realized I was wasting time. About 10 hours later, I made my own light PHP framework. Now I didn't have to worry about my SQL syntax (it was automated based on the data model variables) and I got to start working on really cool/interesting programming issues rather than the mundane blah code. Now I've started to investigate Cocoa again and I realize that libraries and frameworks have not hurt programming, but dramatically catapulted it into the realm of science rather than plug-and-chug. Today, our software is more complex than ever and it will only get more complex in the future. I think if you see programming as just "stitching libraries together", then you've lost your passion or never had any to begin with. Programming has evolved into a science where you have to learn the foundations (languages) AND the pre-existing solutions (libraries) in order to figure out what's been done for you so that you can focus on exploring new and more complex issues.

marshallp 17y ago
I think you need to really learn what sql is. It's a 4th generation language, higher level than php or other oo/procedural/functional langauges. If you're finding php and a framework to be better you're underestimating the power of sql.
- zackham 17y ago
  What about the very common cases where you need to do very simple things, like common CRUD operations? Abstracting the SQL required for these simple queries makes a lot of sense to me.
  - marshallp 17y ago

scorciapino 17y ago

"For me, there is a sort of metallic flavour to most raw tuna;" - yes, it is called Mercury

gamble 17y ago
If you can taste the mercury, you're in trouble.
- scorciapino 17y ago
  That was the point! :)

albemuth 17y ago

I've been feeling like this lately, every now and then there are some interesting problems to solve but more often than not it's all just plumbing...

drgath 17y ago
Every now and again? What?! If you can't find problems with today's internet technology, you aren't looking hard enough.

gamble 17y ago

The problem is not that libraries exist, but the incredible mental investment required to use them. Early libraries were just bundles of functions, but modern libraries are vast, complicated beasts that require years of experience to fully grok. But don't take too long, because they all exist in a state of perpetual churn, and hitching yourself to the wrong train could well destroy your career.

patio11 17y ago

Is this an indictment of frameworks or merely an indictment of bad frameworks? I've worked with both. Trying to manhandle JAX-RS into marshalling your objects in exactly the right fashion such that the XML parser doesn't barf on them is not exactly uplifting work... but it did get something done for my customer. Working with well-designed frameworks, though, is a true joy. It means I spend a minimum of time on plumbing and spend the majority of my efforts solving problems for my customers or otherwise doing high-value work. I understand there are folks out there who love socket programming, but I've done socket programming, and I have no desire to ever touch it again. Good HTTP clients, REST, etc make that totally unnecessary for the types of problems I routinely have to solve. (Speaking of good frameworks versus bad frameworks -- even in Big Freaking Enterprise Java there is a titanic gulf between ways to implement web services. RestEasy is probably the best architechted framework I've ever seen -- it is so good you can forget you're using a web service at all.) My next business will need to make telephone calls. There is a whole lot of very ugly coding necessary to make that happen. Happily, Twilio has apparently already done it for me. I'll just snap together Twilio and Rails to be able to make the customers' phone ring, and concentrate on delivering the smart part of the service, which is that making sure what happens after the phone rings solves a real problem that is preventing their business from making money.

ajross 17y ago
I think it's more an ode to "plumbing". From your tone, I get that you don't see much value in or get much enjoyment from writing a parser, or doing pixel-level image manipulation, or writing extensions to your editor to gete it set up just perfectly, or trying to get your code to fit in a 64k segment, or debugging hardware drivers. But some of us do. We're just different. For you, and most modern programmers, there isn't much value in that stuff, and you don't want to have to do it. And, in the modern world, the truth is we don't have to except in the rarest of circumstances. In the modern world, developers (they aren't called "programmers" anymore, it seems) have the freedom to worry about prioritizing "high value work" to solve their customers' problems. But it wasn't always that way. For some of us, that kind of sucks.

jdietrich 17y ago

My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like. Don't get me wrong, I'm grateful for all of it, but it just doesn't seem like what I was promised when I followed SICP for the first time. It just feels like I spend most of my time scouring through documentation and trying to remember umpteen different sets of syntax and class names rather than actually thinking in code. Back in ye olden days, most programming tasks I performed felt quite natural and painless, just a quiet little chat between me and the compiler. Sometimes longwinded, sometimes repetitive, but I just sat and though and typed and software happened. The work I do these days feels more like being a dogsbody at the tower of babel. I just don't seem to feel fluent in anything much any more. We talk about 'flow' quite a lot in software and I just have to wonder what's happening to us all in that respect. Just like a conversation becomes stilted if the speakers keep having to refer to their phrasebooks and dictionaries, I wonder how much longer it will be possible to retain any sort of flowful state when writing software. Might the idea of mastery disappear forever under a constant torrent of new tools and technologies?

alanthonyc 17y ago
I know exactly how you feel. Having to pick up all those different knowledge sets is something else. However, I balance the fundamental desire to build things against a fundamental desire to build things people can use. It's the pride in me. The closest I came to it a long time ago was when I animated a bunch of search algorithms for a class project in college. That was one of my favorites because I could show my non-geek friends what I was doing and they could appreciate it. It's a big reason why I am now focusing on my web app. The web is at a point where I can build something and get (potentially) millions of people using it. I'll sacrifice some hands-off-ness in my programming for that.
jimbokun 17y ago
I kind of like it. The thing is, most of the languages you mention are pretty good at what they do. Python is a good general purpose language, and Django is just a Python framework, right? (Not a Django developer.) XHTML does a good job describing hierarchical content to be displayed. CSS is a good language for styling content separately from the structure on a site wide basis. JQuery and Javascript can be looked at as a single thing, and if you know the syntax for Javascript data structure literals, you pretty much know JSON. Google App Engine seems to potentially offer a lot for the learning curve required (not an App Engine developer, just read some tutorials). XML, well, there's just no excuse for that. :) Some people complain about all the parts you need to know to build web applications as compared to desktop applications. But I think that the different languages each doing their thing well makes for a better development experience. The other great thing is the diversity of choices for the backend technology stack, like Viaweb deciding to build web apps just so they could avoid Windows and use Lisp (...and some Perl and C++, I think).

brown9-2 17y ago

I want to make things, not just glue things together. When people ask me what I like about my job, I always say the same thing: that its the thrill of starting with nothing and making something. I couldn't agree with this more.

msluyter 17y ago

Yep. I've been going and digging up old ACM and other programming contest problems just so that I don't forget how to actually code something from (near) scratch. I was disturbed to discover how rusty I was.

ern 17y ago
I started doing Project Euler problems for the same reason last year. I even sat up with friends one night working on a few problems, just to recapture that college feeling. But I know writing algorithmically interesting problems are not likely to appear at work, and I've made my peace with that, along with the paycheck I get for writing enterprise systems.

kylemathews 17y ago

My comment I left on the post: I guess it depends on your motivation. I don't program because I love creating complex data structures or innovative new algorithms, I program because I want to create innovative new applications that change how people live, think, work, learn, etc. I signed up for programming so I could change the world for the better in my own little way -- not improve how an electronic machine inputs and outputs binary input. But to each their own. It seems everyone likes to work at different levels of abstractions. I think we can both agree that those electric engineers are weird :)

jimbokun 17y ago

I think to do actual "programming" you need to work for a software company. Google and Facebook and other gargantuan sites have as much interesting CS stuff to work on as you could want. I'm sure many at Apple and Microsoft still get down and dirty with OS internals. There are a lot of companies springing up focused on machine learning over massive datasets. If you are building applications for end users, though, it's hard to justify not leveraging libraries and frameworks that already supply much of what your users want. Especially if the software does not directly make money for your organization.

andywood 17y ago

Wow. I sympathize with this very, very strongly. I think this captures the root of the career frustration that I experience 70% of the time. I seem to spend way too much time on what I call "guessing the magic password" - tracking down that one bit of punctuation in some obscure value in some xml configuration file that makes my whole system fail silently in one environment. I might spend 5 hours beating my head against a wall, only to finally figure out that this brittle system over here needed me to put some proprietary prefix on some host name in this one context. And at the end of it, I don't feel accomplished. I feel like I'm wasting my life! Figuring out which parameters to pass to which APIs in what order is a step above "guessing the magic password" - but it's not that big a step. A few things come to mind. You can try to make sure you are one of the people writing the libraries. You can implement the next platform and use all the aesthetic sense you have in you to try to make it a joy for others to use. Put yourself in the position of the programmers who write the systems that make the rest of us age faster, and try to do a better job. Or content yourself with getting your programming joy from your elegant side-projects.

DanielBMarkham 17y ago
I seem to spend way too much time on what I call "guessing the magic password" It's always been this way, but lately it's gotten worse and worse. You need to fix a problem. Your friends tell you about technology X which seems exactly what you need. So you pick it up, take a quick look at the samples, and wham! Within minutes the thing is working exactly like it is supposed to! Well almost. There's this little part that's broken that ruins the whole thing and then you spend hours or days (yes, perhaps weeks) digging up obscure configuration documentation and tweaking APIs in ancient Klingon, sacrificing turtles to Ba'al or whatever else it takes to get the damn thing working like it's supposed to. Then it's on to something new. The funny part of this whole story is -- when your friends ask you about how programming in X was, you are more than likely to brag about how easy it was to solve your problem. After all, the bulk of the problem was fixed almost instantly. Don't want to look like a dweeb. And so the cycle of pain continues.

bcowcher 17y ago

I think the core of the problem that the OP is experiencing is that most API's are really bad. By bad, I mean the API gets in your face and becomes more hindrance than help. I say, choose your API's wisely, find what helps you and discard the rest.

oconnore 17y ago

GCC?! Real programmers use punch cards. More seriously, abstraction is not the issue. The issue is poorly written libraries and languages that require you to worry about the small details. Your brain can handle many small details or a few big ones, but not both. I recommend picking the latter, and using libraries and languages that allow you to do so. Hint: Lisp is really pretty swell.

jrockway 17y ago
Lisp has libraries?

signa11 17y ago

This is the promised land. Remember hearing how good code re-use is? Now it's here.

joss82 17y ago
Hurray! Now we can focus on what's really making our application different. And it turns out to be boring. Maybe we should be more creative in our application's core functionalities, should we not?

cubicle67 17y ago

This has happened to many industries, not just programming A Pharmacist (not sure what you call them in the US) spends years at Uni learning all about drug manufacture, how the body works etc, and now all they do is type script in the computer and hand over bottles of tablets What does a signwriter do now? It used to be a skilled craft, now all it requires is typing text in a computer that then cuts the letters from a roll of vinyl sheet Or Carpentry or any number of other trades?

jrockway 17y ago

Programming for the sake of programming and programming to solve real-world problems are two different things. The first is more fun, the second is more profitable. Since most people want money rather than fun, most programming is of the second type. If you want to program something fun, nothing is stopping you. Thanks to the libraries, you can concentrate on what interests you, rather than the details of how some standards committee thinks the word "referrer" is spelled.

logicalmind 17y ago
I think your comment hits the nail on the head. I've worked with web apps for a long time and I quickly learned that all I was doing was writing software for some business process. This isn't the sexiest work or the most interesting, but it has never stopped me from doing interesting things. For example, I try constantly make less work for myself. So much of the code we write is boilerplate so I have various tools that generate as much code as possible. I have written mini languages that specify the important parts and then generate all of the plumbing around it. I won't run out of interesting problems until I can generate an application by specifying the important parts (to the business) and generating everything.

sshumaker 17y ago

The whole point of libraries and higher level languages is that they allow you to work at a higher level of abstraction. As the languages and libraries improve, difficult problems become trivial, while impossible problems become merely difficult. Given enough time, problems eventually become trivial enough to be solved by non-programmers. There will always be a frontier - problems that have barely just become solvable thanks to improvements and technology, and these 'very difficult' problems will be what the best and brightest will be drawn to. Maybe the author is working on problems that aren't challenging enough.

rw140 17y ago
I'd take the view that the emphasis has shifted from 'can we do this? / is it possible' to 'how shall we do this? / what will make our users happiest'. Both of these are great aims, but the former is probably more fun. There will still be edges where the emphasis is still on 'is it possible' but as the technology matures, you'll probably have to seek them out, rather than be there automatically.

samratjp 17y ago

It's a pity that so many friends of mine gave up programming after starting out with Java... But, at least MIT didn't ditch Scheme for Java @intro level. Better Python than Java any day :-)

wedesoft 17y ago

This was maybe the main reason why I switched to Ruby. The largest part of my time was spent on integrating other people's work. Don't get me wrong. It would take me more time to write the code from scratch and it would have introduced redundancy. But it just didn't feel right spending so much time on getting other people's stuff play together. I think the problem is that C/C++ and Java don't scale semantically.

nhoj 17y ago

It seems the author of the article is stuck in a problemscape where all the problems he would find interesting are already solved. One solution is to move to a new area of software development that offers challenging problems. I am currently, like many others it seems, working with creating enterprise CRUD-apps and integrating them. I try to find joy in reaching for a skill level where I can produce solutions quickly, solutions that are easy to change, solutions that immediately lets you know where and why an error has occurred, solutions that are secure, solutions that scale, solutions ran in the cloud instead of on servers that it takes it operations months to set up etc. There really aren't that many people out there that can do all of the above well (me included) and there are lots of money to be saved for your employee/clients doing those things well. I think we would see a lot less attempts at off-shoring if more people in enterprise-it would strive for that kind of knowledge. I guess what I'm trying to say is, maybe one shouldn't have too high expectations of the technical challenges in problemscapes that have been mostly solved already but that, at least in my area, there are still challenges to be found. They are just of another kind and maybe you can find them interesting? They keep me interested enough at least. sigh Why am I posting on hacker news again?

motters 17y ago

If you're just plugging libraries together it's a sign that the area of computing in which you're working has ceased to innovate.

nazgulnarsil 17y ago

boo hoo, the wild west days of roll your own everything are gone. except they aren't, you just have to be good enough that companies working on the forefront of non-standard (yet) hardware will hire you.

lurkerperpetual 17y ago

There is fun and exciting work to be done still. The fact that most of us chose to work on boring plumbing has little to do with programming having changed; it became a more diverse field a majority of which is 'commoditized'. So why complain? Go do something interesting. If the problems you are solving as your daily routine are themselves boring why would the process of solving them be any more fun?

ndl 17y ago

Years of research and countless dollars have gone into making programming a systematic, controllable process. Old school managers frequently wish that a dev team would output like an assembly line. Simultaneously, we're expected to be into the newest and coolest technologies. Put these together, and we're supposed to systematically glue everything that's new. Seriously, it's not all bad, though. I like being able to generate a test UI in under an hour or a basic web spider in one python file. The art's just different. It's no longer packing your entire logic into beautiful lines of BASIC. It's now more about choosing the right platform to do something that the user will appreciate. If you're into the pre-library styles, I recommend looking at alternative hardware. When I wrote my first CUDA project, I had to figure out how to get random numbers with sufficient randomness for our physics simulation. You might also look at robots or embedded devices. There's plenty to tinker with on devices that don't have libraries available.

blogdog 17y ago

A very interesting observation.. I tend to agree that the sheer number of frameworks and libraries makes programming into coping with flaws or badly documented "features". The other thing is that the programming world is much like an archipelago, where different islands develop their own programming culture, like .NET or JEE or PHP. And the islands are floating apart: It will become increasingly difficult to establish the better choice because of long learning curves. It is important to admit there are other cultures out there, that even might do a better job in particular areas. However, as much as frameworks get more sophisticated and cater to the programmers ideal of elegant and abstract formulation of the code, Managed Code, Reflection and even OO have a overhead cost in cycles and bytes, particularly when scaling up. As a 45+ programmer I sometimes weep about "elegant" code that drives your machine to the edge but only does a fairly simple job. Stacking API's and frameworks does certainly not always contribute to efficient and simple executables. Sometimes we just need to get back to the root, or at least understand what happens in the machine when we use a certain framework or library. For programmers that will remain a challenge, and fortunately will force us to reflect occasionally...

Kalibus 17y ago

It's just one of those things