6 ms·

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 li

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.

50CNT 10y ago
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.
- at-fates-hands 10y ago
  >>> 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.
  - skybrian 10y ago
    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.
Benjammer 10y ago
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.
- gaius 10y ago
  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.
  - Benjammer 10y ago
    Yeah, that's the connotation I was trying to avoid, that's what I was talking about... >It used to be that your computer had a compiler, and editor, and a shell, and you would go to work, writing code. By "hardcore coder" I just mean someone who thinks ^that^ sounds like a lot of fun.
    - lfowles 10y ago
      And it does sound like a lot of fun.. I just prefer to be able to augment it with StackOverflow/Google :)
- sklogic 10y ago
  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.
green_lunch 10y ago
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.
- bryondowd 10y ago
  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.
  - geophile 10y ago
sanderjd 10y ago
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?
- geophile 10y ago
  It's a very useful thing to do. Except that most of this discussion should be a design review much earlier in the process.
  - sanderjd 10y ago
    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.
jordache 10y ago
really? developing repetitive stuff is fun? I want to re-write low-level mouse driver. Find good libraries and mash it up to your heart's content!
- khedoros 10y ago
  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.
sammydavis 10y ago
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.
- fapjacks 10y ago
  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!
duaneb 10y ago
It seems like you don't like to work with other people. There's a limit to the kind of software you can build entirely yourself.
- sklogic 10y ago
  Yet, this limit is far higher than most people tend to think.

50CNT 10y ago

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.

at-fates-hands 10y ago
>>> 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.
- skybrian 10y ago
  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.

Benjammer 10y ago

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.

gaius 10y ago
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.
- Benjammer 10y ago
  Yeah, that's the connotation I was trying to avoid, that's what I was talking about... >It used to be that your computer had a compiler, and editor, and a shell, and you would go to work, writing code. By "hardcore coder" I just mean someone who thinks ^that^ sounds like a lot of fun.
  - lfowles 10y ago
    And it does sound like a lot of fun.. I just prefer to be able to augment it with StackOverflow/Google :)
sklogic 10y ago
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.

green_lunch 10y ago

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.

bryondowd 10y ago
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.
- geophile 10y ago

sanderjd 10y ago

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?

geophile 10y ago
It's a very useful thing to do. Except that most of this discussion should be a design review much earlier in the process.
- sanderjd 10y ago
  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.

jordache 10y ago

really? developing repetitive stuff is fun? I want to re-write low-level mouse driver. Find good libraries and mash it up to your heart's content!

khedoros 10y ago
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.

sammydavis 10y ago

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.

fapjacks 10y ago
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!

duaneb 10y ago

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

sklogic 10y ago
Yet, this limit is far higher than most people tend to think.