Newsletter Article, Programming Isn't Fun Anymore [modified]
-
But why would you bother pointing out about the "price we pay" unless you believed it was something we weren't cognizant of already? Of course there are some things of this profession I don't like, as you agree in the next sentence. I get the impression you believe you're talking to some PHP guy who believes himself a coder because he tweaked a Drupal theme - yes, in that case you probably DON'T have a professional developer who is familiar with the software lifecycle. I'm talking about professionals who just get frustrated over this particular characteristic and do more complex work. Don't mistake that minor bit of despair I'm discussing here with regret over my choice of profession, or some belief that it should be "all roses", or that I don't or can't handle those bits that suck. I think my tone might indicate to you more discomfort than I'm expressing. I won't stop developing software, and I'll try my best to keep up with things like every other professional dev, as I do know is the price I pay for being a professional. I just want to express that bit of pain and see whether there are other souls who feel this way as well.
Why did you bother pointing out that some parts of our work are frustrating unless you believed it was something the rest of us were not already aware of?
-
Why did you bother pointing out that some parts of our work are frustrating unless you believed it was something the rest of us were not already aware of?
Well, thanks for your contributions, but I think this is getting a little cyclical...
-
Knowing that a screw needs to be removed and that's all the job is ever going to be doesn't make it any more fun to try and figure out what screwdrivers can to be used. And determine if a given screwdriver allows you to turn it the requisite number of times to get the screw out. And whether the screwdriver can handle screws painted blue. And whether the screwdriver can be used anywhere else. Or if it would be cheaper just to buy a whole new [x]. [Apologize for the analogy.]
I get what you are trying to say, but haven't really ever had that issue. The frame works and languages I've been able to work with have normally solved the problem I was trying to pretty easy. Instead the hard part was the constantly changing requirements that I have struggled with. The interesting thing is that if you read the comments in the thread, you will find people on both sides of that fence, those struggling with the frame works or requirements. The one truism I’ve found is that in software development there are always challenges to overcome. Btw, what type of development are you doing? Just wondering why the existing technology poses such a challenge?
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
modified on Friday, September 9, 2011 10:53 AM
-
Little condescending, aren't we? I enjoy the analysis, testing, planning, etc. that goes into setting the STAGE for building a system... if I gave that impression above, that's not what I intended. Figuring out the algorithms for determining how to successfully build a real-time platform where data x from source y needs to be run through systems a/b/c before being placed in a data warehouse for analysis (or some other complex example) is fun to me and to a lot of developers. Where your analogy to a 'regular' architect falls down is that your knowledge of different building materials and types of systems and freaking physics DOESN'T CHANGE EVERY SIX MONTHS. THAT'S my problem. Concrete hasn't gotten obsolete in the last two hundred years. Steel hasn't been replaced by TransparaSteel and left to be only supported on some aging platform because a company or some developers lost interest or found something else that's more in their best interests. I find that aspect frustrating, and I think there's a decent number of people that feel the same way. It's not just Microsoft that decides that some technology they were pimping is suddenly obsolete, won't be further developed and will leave you with the decision to either switch to something else or risk going without security patches and updates to have it deal with newer technologies. And frankly, your concluding statement is just insulting. Devs that agree with the article author and I are quite familiar with the stuff that happens outside the IDE, from analysis to deployment. We wouldn't be reading freaking CodeProject if we were "code monkeys", as it seems you're implying that we are. "Code monkeys" who wouldn't know anything about that outside stuff wouldn't be complaining about it's crazily dynamic nature, would they? A professional commits to improving his craft, and by (loose) definition, someone who is trying to do so and finds some parts of that effort to be incredibly frustrating is still a professional. I work through it, most of those other devs do too. So don't presume that we're not willing to pay that price, and unless you're some software luminary don't presume to define me as a professional or not.
craigsaboe wrote:
. THAT'S my problem. Concrete hasn't gotten obsolete in the last two hundred years. Steel hasn't been replaced by TransparaSteel and left to be only supported on some aging
Actually steel and concrete have changed a lot in the last 200 years. So have the practices of working with those materials :) As we learn more we refine our processes and handling of materials.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
craigsaboe wrote:
. THAT'S my problem. Concrete hasn't gotten obsolete in the last two hundred years. Steel hasn't been replaced by TransparaSteel and left to be only supported on some aging
Actually steel and concrete have changed a lot in the last 200 years. So have the practices of working with those materials :) As we learn more we refine our processes and handling of materials.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
I realize that, there's not a lot that HASN'T changed a lot in the last 200 years. I'm not talking improvements in process or material handling, I'm talking moderate to huge paradigm shifts. Don't get too caught up in the analogy, it's really hard to find a way to express an idea about stuff that only exists in an abstract fashion, like software. You don't think that the way that a lot of software is written has changed tremendously in ten years, or even five? I know you may counter with the fact that enterprises don't move that fast, may still use J2EE or .Net 1.1 or something, and that the flavor of the month in languages isn't necessarily an indicator of the way most devs work. But come on, can't most devs agree that, whether you care and/or enjoy the fast pace of the IT world, it does change at a tremendous rate, more than many other fields?
-
I have also been doing this for 30 years and I must respectfully take another position. In the VB 4-6, VC 4-6 ++ and pre-web Days I was a master of my craft. My tools were always comfortable to me; fit my hand and I only needed one help file once in a while to look up a bit syntax. I had complete confidence that if I accepted a project that I would finish with the customer pleased. Now the majority of project time is digging into how my tools work; when deployed here in this framework, under this hosted site or these security conditions or that this managed code library will… that web service is allowed to… in IIS but not under…looks like this in IE but not in Firefox and oh you use Chrome…and on and on and on. There may not BE a right solution, I cannot certain and I fear for my customer at times. If we can learn to code, yes, we can learn new code and ideas, the linked list, random file access, recordset, ODBC, OLDEB, Entity Model Framwork, LINQtoSQL, ODATA, ad infinitum (that’s just some of MS). We can adapt but should we be forced to? Is the vibe here if you suggest that maybe greater complexity for its own sake is bad that makes you a IT coward? Are we getting something special in exchanged for the treadmill of change that creates endlessly mediocrity of skills? At the end of the day I am still putting names, dates and values on the screen. Same as thirty years ago, but I have to read a damn lot of postings to it. Feel free to ascribe it to some lack on my part but then the hundreds of sites like this one would not exist cause it would just be my problem. We need to own up that the platforms are becoming / have become spaghetti code that change constantly to (a.) make a buck and (b.) fix last quarter’s almost good idea.
Thank GOD someone gets the original article and my point, expressed much better than I put it. It seems many on this board seem to consider this the viewpoint of the "IT" or "Programming coward". Maybe it's ego or something. But how many devs have really got advanced knowledge of each of those data frameworks that the parent just pointed out? And if you somehow do, how much could you have possibly kept up with the progress of any other software or tool? It's not just trying to become proficient in even one technology, it's that proficiency is often attained right when it is superseded by something else, and often for no good reason.
-
I get what you are trying to say, but haven't really ever had that issue. The frame works and languages I've been able to work with have normally solved the problem I was trying to pretty easy. Instead the hard part was the constantly changing requirements that I have struggled with. The interesting thing is that if you read the comments in the thread, you will find people on both sides of that fence, those struggling with the frame works or requirements. The one truism I’ve found is that in software development there are always challenges to overcome. Btw, what type of development are you doing? Just wondering why the existing technology poses such a challenge?
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
modified on Friday, September 9, 2011 10:53 AM
If you read the parent article, and ignore my summary, do you read anything that says that the existing technologies DON'T solve most problems? Or that there aren't BIGGER detriments to project completion? Or bigger challenges? The problem is NOT an inability on mine or the parent's part to get stuff done. Nor is it that we find it too challenging to stay competent as developers. I'm not sure why everyone is getting the impression that we're so frustrated by this that we're going to dump it all and go farm corn. But come on, you don't see what the issue is? Tools and methodologies changing drastically and doing so not always for a real pressing reason. We used to use waterfall, now there's Agile, TDD, Scrum, Aspect-Driven, Behavior-Driven... Yeah, they can make a difference in your productivity, but how much damn time will it take to learn enough to choose between them, and implement them, and experience that productivity? Yet, people (especially managers) are rushing to use these. Cloud development has a ton of promise, too - but there's no good way to move instances around between different providers, there's questions about performance, how much you're tying yourself to an API or a particular provider... Yet there's a big press by a lot of businesses to use these to reduce IT costs. I like Heroku, but it really demands a modification to how you previously developed web apps. And how much do people really understand the drawbacks yet? I'm not sure how to be more specific about what I'm expressing frustration over. If you're able to keep on top of the world of software development and have a solid handle of all the changes occurring not just in your particular situation but everywhere else, including what people are building to succeed what you're writing your software in currently, I applaud you. I just find it akin to a treadmill - you run and run but don't seem to get anywhere.
-
I realize that, there's not a lot that HASN'T changed a lot in the last 200 years. I'm not talking improvements in process or material handling, I'm talking moderate to huge paradigm shifts. Don't get too caught up in the analogy, it's really hard to find a way to express an idea about stuff that only exists in an abstract fashion, like software. You don't think that the way that a lot of software is written has changed tremendously in ten years, or even five? I know you may counter with the fact that enterprises don't move that fast, may still use J2EE or .Net 1.1 or something, and that the flavor of the month in languages isn't necessarily an indicator of the way most devs work. But come on, can't most devs agree that, whether you care and/or enjoy the fast pace of the IT world, it does change at a tremendous rate, more than many other fields?
craigsaboe wrote:
But come on, can't most devs agree that, whether you care and/or enjoy the fast pace of the IT world, it does change at a tremendous rate, more than many other fields?
Maybe that's the difference between our perceptions. I rather enjoy it, though I am not a consultant and work within an enterprise where I largely get to control what technologies I get to work with.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
If you read the parent article, and ignore my summary, do you read anything that says that the existing technologies DON'T solve most problems? Or that there aren't BIGGER detriments to project completion? Or bigger challenges? The problem is NOT an inability on mine or the parent's part to get stuff done. Nor is it that we find it too challenging to stay competent as developers. I'm not sure why everyone is getting the impression that we're so frustrated by this that we're going to dump it all and go farm corn. But come on, you don't see what the issue is? Tools and methodologies changing drastically and doing so not always for a real pressing reason. We used to use waterfall, now there's Agile, TDD, Scrum, Aspect-Driven, Behavior-Driven... Yeah, they can make a difference in your productivity, but how much damn time will it take to learn enough to choose between them, and implement them, and experience that productivity? Yet, people (especially managers) are rushing to use these. Cloud development has a ton of promise, too - but there's no good way to move instances around between different providers, there's questions about performance, how much you're tying yourself to an API or a particular provider... Yet there's a big press by a lot of businesses to use these to reduce IT costs. I like Heroku, but it really demands a modification to how you previously developed web apps. And how much do people really understand the drawbacks yet? I'm not sure how to be more specific about what I'm expressing frustration over. If you're able to keep on top of the world of software development and have a solid handle of all the changes occurring not just in your particular situation but everywhere else, including what people are building to succeed what you're writing your software in currently, I applaud you. I just find it akin to a treadmill - you run and run but don't seem to get anywhere.
craigsaboe wrote:
If you read the parent article, and ignore my summary, do you read anything that says that the existing technologies DON'T solve most problems? Or that there aren't BIGGER detriments to project completion? Or bigger challenges?
I read it when you first posted it. Your first sentence encompass the problems I have, it’s not the tools or paradigms that cause me pains it’s entirely the human factor. Perhaps your challenges (I’m not calling you daft by any stretch of the imagination) are that as a consultant you are expected to walk into any house and pickup the tools they are using and adapt to their principals. I know I’ve had some interesting conversations with some of the oracle consultants we have had. My perspective is; I have to support it once they leave. So they are going to follow my standards (unless there is a good reason for doing it the way they want to). Almost all of my development is easy; it’s almost all TSQL or PLSQL (forgot SSIS but that's just fun). It largely is just a matter of figuring out how the users want the data to look and work (multi dimensional dbs). The real fun is reverse engineering the data models of the applications we have purchased.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
Did this newsletter article really resonate with anyone else? It's slashdotted (codeprojected maybe?) so here's the GCache link: http://bit.ly/qNbGv6[^]. I know it's in the nature of a programmer to be working in a dynamic field, moreso than many others; but ****, is it frustrating when you want to build someone a relatively simple website with some standard features and a few new "things", and you have to spend however many hours evaluating not just languages but platforms and frameworks and communities and future plans and everything else. It's not just Ruby/Rails, the poster child for programmers with ADHD; it's also PHP, easy to deploy on most hosts but with 168 frameworks you need to spend several hours each to evaluate, only to figure out that someone with delusions of grandeur wrote the routing engine. Honestly, I want to code, become really familiar with one stack, so that I can focus on really great solutions with it. If I want to check out some new paradigms, then I can without having to do so just to find work. Yeah, maybe not the "ideal programmer", but having been doing this only 6 years... it's frustrating to me.
modified on Tuesday, September 6, 2011 11:34 AM
It totally resonated with me. A few weeks back I totally had a "Peter Gibbons" day at work and just flat out wanted to change [i]careers[/i] - not go to a different employer, just flat out stop programming. I'm not sure why exactly I started feeling this way, but this article really hit a nerve with me. It's just flat out not fun. I have a co-worker that is consistently changing frameworks, APIs, new implementations, and find out how to "weave" them in to our infrastructure. It's like buying an erector set, then seeing that Lego has something you like, but instead of challenging yourself to make the same thing w/ what YOU have, you spend 4x as much time making your stuff work w/ the Legos... ugh.