|
I've done similar jobs in places where it has been an absolute pleasure and places that have sapped every last ounce of joy from me. If I were to list all the jobs I've ever had in terms of how much fun they were, there would be coding jobs at the top and the very, very bottom of the list.
It's not the activity that determines whether or not a job is fun, it's the people that your with and that holds true whatever you do for a living.
Slogans aren't solutions.
|
|
|
|
|
Jeremy Falcon
|
|
|
|
|
Also the required "process" to move from coding to production. I can make a change, and even if its correct, the documentation, testing, going through approvals, etc, etc, are mind numbing. So wrong people on top of that makes it even worse...
|
|
|
|
|
Absolutely. The coding part is great. Then comes the documentation. Oh the pain...
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
I'm not doing the same thing for the 32767th time, which happens often in my workplace due to having about a thousand of different branches of the same software with strange derivation trees and the same features implemented in dozens different ways by different programmers in different point in time with several different underlying models.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Just do it the -1th time, that should be enough.
|
|
|
|
|
Enjoyable, interesting, fascinating and eminently satisfying would be better adjectives.
Fun is for playing with the kids or the dog or down the beach.
|
|
|
|
|
My Dear Mycroft, at least your subject passes the spell checker.
Sincerely,
Sherlock
|
|
|
|
|
Mycroft Holmes wrote: Enjoyable, interesting, fascinating and eminently satisfying would be better adjectives. I thought the same thing. I do remember it being 'fun' in the beginning...before it turned into work.
"Go forth into the source" - Neal Morse
|
|
|
|
|
It's fun - but it's also how we generally make or money, so we have to accept that it contains "dull bits": formal documentation, grinding out basic code which needs little thinking about. But that's important because it means that we can pick it up again later.
Think about it this way: you spend 1/3rd of your life asleep. At least 1/3rd at work. And probably the other 1/3rd commuting, winding down, sick, or on the loo. If you don't enjoy your work, if that isn't fun, you are in the wrong job, and it is going to break you...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
That reminds me of a routine that Jasper Carrot used to do where he'd read out various statistics about how much of your life was spent in traffic jams, sitting on the khazi or whatever then asked you to imagine having to do it all in one go.
Now, I reckon I must have spent somewhere between 40 and 50 thousand hours coding or doing related activities. Quite frankly, if I spent 40 or 50 thousand hours of my life doing anything, no matter how improbably fun-packed it might be, the fun factor would be running pretty low by now.
Slogans aren't solutions.
|
|
|
|
|
Nobody pays me for furnicating, eating and playing videogames so I had to take the fourth best option.
Well I'd enjoy being a gunsmith but the only places I could do it the right way aren't exactly immigrant friendly...
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Just like bungee... Even more fun when you realize - in the middle of falling - that the rope a) not so elastic or b) cut...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
a lot of my work is to change or update the UI after some fancy ideas of the UI designers or managment.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
|
Coding is no more 'FUN' when requirement change 'FREQUENTLY'
(**I think, Requirements will not freeze until last user dead )
|
|
|
|
|
Of course it is! They happen - we all know that! So design for changes, prepare for changes, and see them as a challenge. They are there to make the final product better to use - so embrace them, expect them, and make your code flexible enough to absorb them!
And if all else fails, blame them for your late delivery / bugs / total failure of the project - and demand a pay raise!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
You would have serious trouble on our team, requirements tend to be what we can extract from the users when they are not too busy to talk to us.
When we then deliver the prototype we actually get some idea of what they really want.
|
|
|
|
|
Make sure that you get paid every time they change it, and that there is formal processes that needs to be followed in case of a change. We've fallen in the trap of customers talking directly to the developers about changing a requirement just quickly. This change was many times undocumented and nobody knew about it. It was done for free. Sometimes even a big shot at your company (e.g. CEO) want you to change something quickly.... these changes are nono's. If something needs to change, your project manager should come to you and ask you to provide him with the amount of hours it would take to change this thing. He should then add some time to that for in case it can't be done within that timeframe and multiply that with whatever the rate per hour is. Then he should give that to the marketing people who have their own agenda's and finally the price of the change is sent to the customer.
At the end of the day the customer should, before changing the requirement know how much it is going to cost to change the requirement.
Lots of times they will see than keeping something the way it is, is sufficient. That it is not worth the money you are charging for changing the requirement. Or they keep it the way it is until they have money to change it, thereby delaying the process.
|
|
|
|
|
At work I'm mostly doing SSIS, which is dreary, but I try to find something to code.
Other than that, Code Project provides ample opportunity to exercise my little grey cells so I can continue to enjoy it.
Thanks, Chris!
|
|
|
|
|
Stop bragging.
Here is what you mean:
At work I'm mostly trying to get SSIS working, but I try to find something to code.
Other than that, Code Project Q & A provides ample opportunity to pull my little grey hair so I can continue to swear even when I am not working with SSIS.
PS: Does quote selected text button work for you? For me it posted the reply.
|
|
|
|
|
Hmmm, yes, we are in similar boats. Except, while SSIS might be considered programming, it is definitely not coding.
I have to dig around to come up with things to code before my boss notices.
|
|
|
|
|
How would your customer react if you wrote in email that "I am running for ISIS jobs" instead of "I am running SSIS jobs."?
|
|
|
|
|
I get SSIS to work as well as it can, but it doesn't scale to meet our needs, so I'd much rather do it the right way.
lw@zi wrote: PS: Does quote selected text button work for you? For me it posted the reply.
Seems OK to me.
|
|
|
|