If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Tired and sick of programming

Hi, I am coding since 20 years now. I started in Pascal, Assembler. And yes, I am getting tired and sick of this job. I couldn't be even working in coding anymore if it wouldn't because I am freelancing since 2004. Even freelancing and doing things your own way you GET SICK of coding as well. Sorry

I will point out my reasons:

1. "Having to change things that always worked", just because third-parties, technological changes, or simply 'the world outside' your program force you to change what was always working. i.e. you develop a scraper/crawler and the target site changes their html/css, thus, your scraper doesn't work anymore. i.e. - You develop financing software that work against SQL Server, then customer/boss decides to migrate database server to Linux, then you have to change most of your SQL code on 10k lines program to 'just adapt' to mySQL syntax. It's not the same syntax in some cases. Or you develop that program in .net and your customer/boss decides to go Linux, then you have to re-write it in C. These kind of things to "re-do" what was working 100% perfect and took you years doing it, well, it's far to be fun, no matter the money involved. What it tires is simply that "you HAVE to" modify what was working perfectly, for reasons besides you

2. "Time spent on analysis, diagramming, structuring". Coding is not like other jobs, you have to THINK how to code it before you code it, in the majority of cases. When the reality you are modelling is complex, well, you have an extra load to "think" first, then "act". And this can be specially tiresome, when you have to work on 10 different projects over a month just to get the bills paid. Specially when you have a customer/boss who's asking you useless things to do that really doesn't contribute to the quality of the software but to ruin your day adding extra, unnecessary complexities

3. "Money". I will be short on this, we all know that this job should be paid X 3 what's being paid considering the effort required. Specially freelancing online. Considering the complexity of this work, we are paid less than secretary work, most of the times. I have not anything against secretaries, but come on, you can't compare writing letters in Word and using Excel compared to what it takes to code even the smallest thing

4. "Inherent difficulty about this profession". In fact, what tires you the most relies on the difficult, unpractical thinking process required to come up with something that may run. When you reach a certain age, and when you have a certain amount of years doing what you do, you follow your own standards, and your standards are high. This means: spend more time doing what you did when you was a kid, when you worked more in a "bohemian" way, just for the fun of it. You stick to your own standards, clarity in code, naming conventions, in a way: you become professional, compared to how you did it when you were 16yr old teenager. i.e. you can easily assign var1, var2, and a, b, c as variable names when you are a kid, without caring if you ever have to modify the program after 1 year. Now, there are times when you have to even spend time thinking how to name a variable, properly declare types, how to name files as a whole, folder/subfolder structures, and so on and on and on. And these are just the basics, the same go to the way you name your functions, the perfect nesting of code. Things that themselves go besides if the program works or not, it's all about standards. You become a professional at what you become after doing it for 20 years. Thus, you can't name a variable as a, b or c anymore.

5. "Perfection", you get obsessed when you are a programmer. 20 years doing it, you have nearly a compulsive obsession disorder of 20 years. Seriously, it's just not "doing it", it's just not enough. It's all about "doing it perfectly, consistent to the way you did it for the last project, respecting a way of doing things, your own way". It's simply impossible when you reach a certain level on this career doing the same thing differently between two programs. As long as it's the same thing you will tend to use one or the other as a code template, and just expand it the minimum possible to avoid breaking away from that code template, a code template you had to think in the first place. And there's the problem that "that code template" just doesn't adjust exactly to what you have to do on the 2nd. project, so you get like a feeling of coldness running through your spine. True story. After 20 years, you need to be consistent, it's more important being consistent and perfect on what you do than the program itself. Talk about "code re-usability obsession" disorder, if it exists

6. "Tired of being the genius kid". Well, this is nice when you are 16 and everybody looks at you like the genius you are. When you are nearly 40 you want to do your thing, get the paypal payment and watch a movie with your kids or wife, have sex, drink whisky or simply listen Megadeth at 9/10 volume. You get tired of carrying the heavy burden of being "the genius kid" that everybody throws the worst **** possible on earth because you will be able to deal with it. You simply want to get a cool life as everybody else, because before being a programmer you a are a human being and you don't want to be constantly thinking, worrying and thinking and worrying and thinking and worrying, when you eat, when you get your bath, when you put the dog to pee, when you are in the bus, when you are in the bed. I lost count how many times I wake up on the morning and stay 1 hour without being able to step up, simply because I am worried thinking on al algorithm or whatever other coding-related **** that kept unresolved from the previous day

7. Finally, the always "need to adapt to a technology that you don't want to adapt". I mean, think of DOS days. Think of Cobol, Fortran; old dudes that spent learning that, plus Pascal, C, Clipper, from 1980 to 1995 to one day JUST throw it all in the WC because Microsoft came out saying that DOS was dead and Windows was there to stay, which meant: "Hey dude, you better start learning VB, Foxpro, VC++, Event-driven programming, Access and SQL Server databases and so on or you are out of the game ". That was a big change. And it happened to me, I was a Pascal, C, 8088 Assembler expert. Now where would I be nowadays coding in all that? The same happened in 2000 with .net. Then Javascript came out, then AJAX.. Now there's all about tablets and "responsive" designs for web. Now we also have the touchscreen madness and all events related to that. It's enough for me. World needs to understand that we don't have to re-learn our career every year just because the childish market "changes" to what the childish market thinks it's better for the market. This is, I think, mainly the main reason of all 7 reasons. You get sick of this profession if you have to re-learn everything one year after another, it's like you always feel a hole, a hole that never gets filled. The only solution to this is working for your own, and EVEN doing so, you are forced to re-learn some things. i.e. think of Table-based web design compared to CSS-table-less design. That was another big change that nobody asked us if we wanted to move through, in the first place. Think of CMS-website design world too, WP, Joomla. Now, some of these called standards are terrible to learn, buggy, wrong, and simply unpractical for the everyday use. Think of Javascript, I am sure you had a hard time more than a single time, trying to get some things to work, looked at the code and looked correct. But, wait, "you forgot that you typed a capital L instead of lowercase l" in your document.Location.href= line, thus, it wasn't working. How can you forget THAT dude!? Now, think if you have 3 pages of complex, event-driven Javascript code written running on your old Windows 98, IE 6 back in 2002 days, without Firefox, Firebug, Chrome and all what we have now to inspect and debug. Good luck trying to see where the error was

As a conclusion, these are the reasons why coding sucks, it's simply too much time-consuming. It has nothing to do with coding for yourself on big/interesting/rehearsal projects. It's all the same after all, then you get tied to keep making enhancements to that "program of yours" and new versions, and it becomes an endless loop. And nothing keeps you free you that one given day you will have to re-write your 5-years development project from scratch just because nobody will use Windows/Linux anymore, simply because a new SO came out, and the market forces you to move along

Positive vibe

Hi Diego,

First off, I am really sad you are tired of this industry. I registered in this forum, after a friend sent me this link, just to introduce a positive vibe and maybe, if you're not yet "burned" - which can be the case -, maybe I can give you a new perspective or a new road to follow regarding your set points towards leaving the industry.
Please, I want you to get my intention: I am not into this to bash you, nor flame you. I just want to give you wisdom from my experience.

I've been a developer in Portugal for 24 years, probably one of the worst countries to deal with businesses, even signing contracts and not getting payed. Besides my experience, here's how I would address these problems you state here.

1."Having to change things that always worked"
If you're a freelancer, you can choose your fights. That means, if you're not desperate to get work, you can choose your projects. As soon as a project is done (aka scrapper), it's done. It should be stated that these kinds of projects are one-shot and have some risks associated. When you get a project proposal out there, specify your boundaries. Set milestones, get paid on deliverables upon some goals achieved. Once the customer pays up a part, he will be hard pressed to keep the plan. If he's hard pressing you on changes, take note of them and tell him this will be added on the current project and needs to be budgeted afterwards. If you don't want to do that change, budget 3 times higher. He will be hard pressed to contact another developer. If he does not, with 3 times higher, budget you can outsource it to another developer. If he insists on the changes within the development cycle, simply refuse - SAY NO! - and deliver what is done. Better to get rid of a problem earlier than later, when you have invested much more time.

2. "Time spent on analysis, diagramming, structuring"
This goes with work methodology. My experience taught me to close business specs before getting into technical details. Generally a customer comes to you and asks how much for a project so and so. If you do not have a finished business spec, your quote is always failing. Best advice is to state first hand your initial quote is a generic estimate (as generic as the initial project description your customer delivered) and will be changed upon a full business spec, that is mandatory; second point is to get your own generic estimate and add 45% more for everything that might be hidden in your customer's mind. If he decides to go forward you need a complete business spec.
As soon as you have a business roadmap, you can finish budget, time and milestones. You get all project features into packages, each package into task lists and each task list into tasks. These tasks should be simple enough to estimate (ex. do a form mail). After you get all tasks you need to do, you should also be able to do the data model. With all these you can set the time for each task, task list and package. Finally you have the project full time. Add an extra 20% or 30% for everything you are not seeing through right now, smaller cosmetic changes your customer might require (everything above 30m to change or changes above 4 hours work should be set on a different budget, a backlog for a version 2 of the project). This time spent should be included in your budget. It is necessary and mandatory because being a freelancer means you are your own sales rep and project manager. This second point represents both.

3. "Money"
I agree with you that it may "feel" you are not getting paid right. This is surely due to poor planning (check point 2), picking poor projects (check point 1) or poor customers.
When you are desperate for work, this gets an increasingly difficult problem. As every company, you need to have your finances in check. You need to have, as a freelancer, at least 6 months lifestyle money security, so you can be comfortable picking your work.
As soon as your work is done and if your customer is satisfied, more work from the same customer will come your way. Generally the first work is cheap, to get you to earn the customer. Everybody knows this, even your customer. Best chance is your customer is tired to spend money on poor programmers. If one delivers good work, best chance is he'll rehire you. He'll be expecting you to increase prices - you need to make sure, as your own sales rep, you're showing off your awesome professional work and as a first work, you'll willing to lower the value of your work to earn his trust.
As soon as you get a load of work coming your way, be sure to "fire" your poor customers in a great customer service way - shut the door gracefully. They will understand you have a lot of work, being a good professional and if they want to really hire you, they'll know they need to pay extra.
I've always proceeded this way and always got 90%+ rehire rate.

(I wrote a long statement but timeout occurred on the login and the forum didn't saved all what I wrote which frustrated me a bit right now. If there's interest on the next replies I will write them here =).