Newsletter Article, Programming Isn't Fun Anymore [modified]
-
I don't think so, but that's one I was able to find via search. It must have been some completely other feature. Thanks for the effort. Also, in regard to your 301: As you can imagine, I usually open Control and Form files in the editor, rarely in the designer, and a per-file setting isn't what I want, so I set the editor as the default... In Solution Explorer, right-click a Form file, click Open With..., select CSharp Editor, click Set as Default. This way the icons remain unchanged, but the editor opens when I double-click a Form file. To open the Designer instead, right-click the file and click View Designer.
Thanks for the suggestion, I never had tried it. Also, I'm still using VS2008 most of the time, that is why my article isn't up-to-date... :thumbsup:
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
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
-
Architects can make those decisions based on high-level understandings of platforms/languages/build tools/dependencies/etc. without having to actually implement said decisions in the trenches? It's a little trite, but some architects seem to be people giving relationship advice to someone who's going out on dates with a bunch of different people. They may think person x is the right person for you, but they're not the one dealing day in and day out with person x and all their little quirks that range from minor to crazy. And unlike women, you can't just break up with your logging framework or whatever if you've got it deployed everywhere. I can enjoy evaluating different programming tools, but that doesn't make the commitment to one easier; for me it makes it more difficult, because you're constantly wondering if that new tool would make your life rainbows and unicorns (or at least, with fewer headaches).
-
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 is called being a professional not just a hacker. If our profession were that of an architect we would have to know how to build on sand, bedrock and everything in between. We would build houses, garages, apartment blocks, skyscrapers and bridges. Of course if you wanted to just build chicken coops you might make a living, you would certainly know, after a while, how to do everything there is in the world of chicken coops and some of your chicken coops might be amazing. You could not however justify calling yourself an architect. Sitting down and just cutting code can be fun, the analysis planning, testing and dealing with varied technologies and difficult clients is also a very important part of the job. Like it or not it is the price you pay for being a professional software engineer.
-
The
Returnkey isn't available in his chosen language.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Return is for the weak. One should never look back.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
It is called being a professional not just a hacker. If our profession were that of an architect we would have to know how to build on sand, bedrock and everything in between. We would build houses, garages, apartment blocks, skyscrapers and bridges. Of course if you wanted to just build chicken coops you might make a living, you would certainly know, after a while, how to do everything there is in the world of chicken coops and some of your chicken coops might be amazing. You could not however justify calling yourself an architect. Sitting down and just cutting code can be fun, the analysis planning, testing and dealing with varied technologies and difficult clients is also a very important part of the job. Like it or not it is the price you pay for being a professional software engineer.
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:
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.
That's why I never build stuff for clients in new tech. I'd rather we spent some time playing around R&Ding with a particular technology, rather than trying it out on the clients. By doing this, there's less pressure on you to lever code into solving one part of a particular problem - instead, you can spend time trying to get a broader understanding of how things work and what you need to do. This is why it took us 18 months from starting to play around with WPF to actually using it on a daily basis with our clients. Basically, never try out new tech on clients - it's only going to end up blowing up in both your faces.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Pete O'Hanlon wrote:
I'd rather we spent some time playing around R&Ding with a particular technology, rather than trying it out on the clients
I just wish everyone thought like you. I've participated on a project from a contractor and the project leader said it would require Sharepoint license. Since I was at the client side and I wasn't involved on requirement analysis, all I could do was accept it. Later I had to maintain the application and I learned that the application was simple CRUD and reporting application as far as the front-end is concerned. It cost the company a good amount of money for the sharepoint license, when obviously a simple asp.net front-end would do it. Instead, because the contractor used us a lab mouse, we ended up with a costlier, difficult to maintain and deploy application which used Infopath forms hosted on a Sharepoint Server. If only I could give my 2¢ in the appropriate moment... Sometimes it just amazes me how people are picked to decide about things they are ignorant about. If I had been consulted I'd have saved money and time for the company. It was so obvious that we were used as an experiment to train the contractor's development team.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
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.
It would seem that you read my reply to your post as condescending. I apologise that was not my intent. My final statement to which you seem to take so much offence simply stated ‘Like it or not it is the price you pay for being a professional software engineer.’ That is not a dig at you or anyone else it is simply a statement of fact. A bit like saying postmen work in the rain or farmers work in manure. That is the price they pay; there is no implication that they are anything but very good postmen or farmers. It would seem that you do not like some aspects of our wonderful profession or at least do not find them fun anymore. There is quite a lot that I do not like and I have been at it for twenty five years so I have seen most of what is on offer but I still enjoy my job. I handle the frustrating non fun bits and accept that life is never all roses.
-
It would seem that you read my reply to your post as condescending. I apologise that was not my intent. My final statement to which you seem to take so much offence simply stated ‘Like it or not it is the price you pay for being a professional software engineer.’ That is not a dig at you or anyone else it is simply a statement of fact. A bit like saying postmen work in the rain or farmers work in manure. That is the price they pay; there is no implication that they are anything but very good postmen or farmers. It would seem that you do not like some aspects of our wonderful profession or at least do not find them fun anymore. There is quite a lot that I do not like and I have been at it for twenty five years so I have seen most of what is on offer but I still enjoy my job. I handle the frustrating non fun bits and accept that life is never all roses.
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.
-
I've been doing this for over 30 years. Imagine how I must feel... You can't possibly become intimately familiar with every nuance of every language and/or framework. The best you can hope for is to become extremely good at what's currently putting beans on the table, and if the need arises, go with the flow and learn whatever else you need to learn as you need to learn it. It's called "adaptation". The nature of computer work is change. Embrace it, or die.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997I 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.
-
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.
