|
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.
|
|
|
|
|
I once did an SSIS ETL package.
Step 1 - read in source file
Step 2 - call script in c# that opens a connection to the database and bulk copies the data into a staging table
Step 2a - script calls stored procedure to do the transforms.
This style scales nicely
|
|
|
|
|
I guess subject says it all.
I do not like everything I need to do at work but if I break down my responsibilities to programming and non-programming ones, I sure love former.
|
|
|
|
|
The only time I have fun at work is when I'm programming. The rest is brutal!
modified 28-Nov-16 0:29am.
|
|
|
|