|
I do it for the same company for over 15 year, and still interesting...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
All the time.
Be it Accounts based, Tech or Administrative it is my job to be on top of it.
Proactive (how I hate that word) Management it is called.
---------------------------------
Obscurum per obscurius.
Ad astra per alas porci.
Quidquid latine dictum sit, altum videtur .
|
|
|
|
|
Dalek Dave wrote: Proactive (how I hate that word) Management
How about "Thinking Ahead"?
speramus in juniperus
|
|
|
|
|
I always prefered "Drive" or "Driven" though marketing and sales always manage to ruin a word by repeating 50,000 times.
Simon Lee Shugar (Software Developer)
www.simonshugar.co.uk
"If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
|
|
|
|
|
Everytime. when a new project comes. I take it or forced to take alternatively.
|
|
|
|
|
All the time. Nature of the job.
At 3am when the power failed, in the middle of the north sea, there isn't usually a lot the people above can do!
|
|
|
|
|
DaveAuld wrote: there isn't usually a lot the people above can do!
Don't be rude, they'll be more worried than you! What if there was a loss of...
...money?
speramus in juniperus
|
|
|
|
|
|
Yes most of the time but mainly technology related. And good think is my company doesn't ignore my suggestions. Most of the time they implement it. Or I should say I implement it and they pay for it.
|
|
|
|
|
Every minute - I am steering the company towards understanding that we need specifications(all the work is internal work).
The advantage is I have a very large creative input - the bad part is the 'can you shift this to the left half a pixel', then the next week 'can you shift this to the right one quarter of a pixel'.
I am lucky to have very understanding, patient and intelligent customers which makes my job enjoyable
I err on the side of preferring having lots of creative input.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It is a part of my job, as others have already said. I do research and proof of concept prototype design. We also do quite a bit of improvisation when it comes to getting the bits and pieces of software and hardware to work together. Initiative is a requirement to do what we do.
I think software in general needs people who take the initiative, many times management has no clue how to implement software and take the "does it work?" and "just make it work" approach.
It was broke, so I fixed it.
|
|
|
|
|
More often than I'd like, as odd as that sounds.
But when you see a carload of drunks heading full tilt boogie towards a brick wall at 120mph, you've got to say SOMEthing, if only so you can work in peace.
|
|
|
|
|
mikepwilson wrote: a carload of drunks heading full tilt boogie towards a brick wall at 120mph,you've got to say SOMEthing I would say WOW! Did you just see that!? Hopefully they are all lawyers.
It was broke, so I fixed it.
|
|
|
|
|
I tried twice:
1. To save hundreds of pages of printout each comprising 5 or 6 line URLs sent to every employee of the company. On average 5 pages per mailing every fortnight. When I suggested that putting this information on our intranet website and sending an email with a link, the response was, "we will take it under advisement": AKA you are a foreign no nothing, please don't tell us how to do our job.
2. I tried to explain to our management why the project I was working on was not being managed properly, and how the technical documentation was not clear enough for the developer (me) to produce a working system. Much the same response, i.e shut up and do your job.
Lesson learned, keep your mouth shut and your head down.
Veni, vidi, abiit domum
|
|
|
|
|
I would of said you were in the right and they at the very least should of listened and considered, developers are thinkers, it's what we're paid to do.
Simon Lee Shugar (Software Developer)
www.simonshugar.co.uk
"If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
|
|
|
|
|
That assumes they were willing to accept that someone else may have known something that they did not. Our general experience with in-house departments was that they believed they knew everythig, and refused to accept that they could ever be in the wrong.
Veni, vidi, abiit domum
|
|
|
|
|
Simon Lee Shugar wrote: do you speak to someone higher up not with just a complaint but a resolve to fix this? ..sometimes it's there for a reason.
Simon Lee Shugar wrote: How often do you take the initiative in your company? If it ain't broke, don't touch it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Cure one bug it 'seems' to work, acid test , out crawls another, I feel like that bloke who had push a round stone up a hill only to have it roll down again (Sisyphus). You cure one bug another one happens! I am getting just do the 'do the changes asked for, make sure it runs & ship it, Not a rewrite as I can't afford you to be caught up doing tech support for them and they need it to be robust', 'but... ' How can a piece of software that runs by luck be considered robust, you fart near it, it falls flat on its face!
|
|
|
|
|
it shouldn´t be, but often a release is saying to the customer how great the product is and diving for cover the moment he walks out the door.
good luck
|
|
|
|
|
I fraggin' Need it! Thanks
|
|
|
|
|
I know thy ordeal...
and I like the farting part .
Mislim, dakle jeo sam.
|
|
|
|
|
If it needs to robust, just rewrite the thing! Quicker, Easier & Cheaper!! but no 'its there problem if it doesn't work'...nice idea if IMHO it stops working who gets call/yelled at the last person to have anything to do with it.
|
|
|
|
|
glennPattonWork wrote: How can a piece of software that runs by luck be considered robust, you fart near it, it falls flat on its face!
A couple weeks ago I told a client I'm off the project. Along the lines of some article I read about contracting was the wisdom "Learn to say no even to money." The application, a crowdfunding website, is based on the open source project "catarse" (Ruby on Rails), and my fork of it (July 2013 or so) was what I was working with. Let's see:
The code is insane - it look like different people worked on it with different technology stacks
It's unstable - for example, emails are incorrectly sent to me for some projects, but not others, and I have no idea why.
It's overly complex - the use of events when straight forward code would have worked, layers of weird code between "do A" and "I'm doing A".
Ridiculous uses of technology - a one-off no-sql database being used to store a single value, once in the code, that is referenced somewhere else only once, but requires a completely separate daemon process to be running to support this critical path code.
Incomprehensible behavior - the whole behavior around what happens when a project expires is crazy, depending on a separate daemon task to update state and still remains a complete mystery as to how some states are transitioned.
It was too much!!! I couldn't separate out the hatred I started developing for the thing. But besides learning some actually cool stuff, I also learned something important about time and money. As long as there is some standard of efficiency to my time, then there's an equivalence to $'s. When the efficiency of the time utilization starts to nose dive, the "value" of the $'s being earned for that time diminishes rapidly. Why? Because I also want to be doing other things. And of course, because the $'s didn't increase for the same unit of time, the time-value per $ ratio started to get seriously out of whack. And that's what led me to saying "NO!"
Marc
|
|
|
|
|
It looking more and more like a band aid job...
|
|
|
|
|
glennPattonWork wrote: software that runs by luck Still working on that VB project then?
It was broke, so I fixed it.
|
|
|
|