 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Staff requests equate to people standing outside my door asking me to
> fix it. Perhaps "time to fix" rather than "time to respond" would be a
> better measure. It would still require somebody to actually *measure*
> this stuff.
Most places I've been at use a database to log all this automatically.
Even if you still want to allow people to turn up at your door, it only
takes a few seconds to log it into the database. You can then use it as
a kind of "to-do" list as well if you want.
> Ditto for uptime. Systems were a bit unstable when I joined, but within
> a few years everything was stable enough
Even if the senior management there weren't interested, don't you think
it would have been nice to be able to produce actual numbers rather than
"it used to be a bit unstable but it's better now"? If even to only put
on your CV for future jobs.
> "Implement new system to increase performance" would require that
> somebody actually give me the *money* to perform badly-needed upgrades.
> Never gonna happen. :-P
There's other things, like software solutions to make things easier/more
efficient to do.
> Basically, for the best part of ten years, all I really did was swap the
> backup tapes once a week.
But you could have done more?
> Not really. There is no long-term plan. We just show up each day and
> mungle on with writing the code. Deadlines don't really exist.
So if you only pretend to work for the next 3 months and don't actually
write any code, nobody will care? I find that really hard to believe.
Where does the company get its money from to pay your salary?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Nov 2013 09:07:46 +0000, Orchid Win7 v1 wrote:
> On 13/11/2013 01:00 AM, Jim Henderson wrote:
>> On Tue, 12 Nov 2013 19:16:28 +0000, Orchid Win7 v1 wrote:
>>
>>> Basically, for the best part of ten years, all I really did was swap
>>> the backup tapes once a week.
>>
>> I seem to recall you did end user support, too.
>
> Yes. Hopefully if you're doing your job well, users won't often need to
> speak to you. ;-)
>
> [There's always wetware issues, of course...]
Of course. :)
But supporting end users is something that directly affects the company
bottom line - you help them be more productive. So for something like
that, "resolved user issues in an average of 30 minutes" or something is
a specific, measurable result.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-11-2013 20:17, Orchid Win7 v1 wrote:
> On 12/11/2013 02:13 PM, Francois Labreque wrote:
>>> At this point, I have to wonder - why am I filling this form out again?
>>> What "goals" or "achievements" can I invent to put in these boxes? How
>>> can I pretend these are related to the company mission?
>>>
>>
>> Did you have any deadlines? Did you meet them?
>>
>> Did you resolve any big problem that was delaying a project?
>>
>> Did you find ways of making XYZ run faster? By how much?
>>
>> Was your code relevant to anything the company did? How so? Would the
>> company have fared any worse without your code?
>
> At my previous place, the answer to all of the above is pretty much "no".
>
> At my current place... well, they pay me to write code all day long. If
> I hadn't written that code, somebody else would have written it, which
> means it would have taken the company slightly longer to get where it is
> now.
That sort of implies that you have no skills that are unique. I find
that hard to believe. There are probably specific tasks that people turn
to you to. Either because you do them faster or better. Better either
because more readable or more thorough.
Some of these things might even be related to Haskell as a spill over.
Not that you use the language, but you may use techniques borrowed from
there.
--
Everytime the IT department forbids something that a researcher deems
necessary for her work there will be another hole in the firewall.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Basically, for the best part of ten years, all I really did was swap the
>> backup tapes once a week.
>
> But you could have done more?
Not really. Once HQ started to get involved, they seemed to perceive me
as some kind of incompetent moron [which, oddly, is how I perceived them
- based on actual *evidence*], and they seemed keen to take as much
control away from me as possible...
>> Not really. There is no long-term plan. We just show up each day and
>> mungle on with writing the code. Deadlines don't really exist.
>
> So if you only pretend to work for the next 3 months and don't actually
> write any code, nobody will care? I find that really hard to believe.
> Where does the company get its money from to pay your salary?
If it were noticed that I was only pretending to work, I'd probably be
fired on the spot. That doesn't mean that my work is critical to meeting
deadlines - it's just that, why would you pay somebody to do nothing?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> At my current place... well, they pay me to write code all day long. If
>> I hadn't written that code, somebody else would have written it, which
>> means it would have taken the company slightly longer to get where it is
>> now.
>
> That sort of implies that you have no skills that are unique. I find
> that hard to believe.
Well, we all know how to write code, so...
> There are probably specific tasks that people turn
> to you to. Either because you do them faster or better. Better either
> because more readable or more thorough.
Mostly people turn to me because I happen to be the guy who wrote
function X, and how does that work again? I could look it up, but it's
quicker to ask you...
> Some of these things might even be related to Haskell as a spill over.
> Not that you use the language, but you may use techniques borrowed from
> there.
Heh, I still remember the day I wrote some code that parses a particular
file, and I wrote it as a nice isolated function that takes the file
contents (which is data) and returns the parsed result (which is data),
and then a tiny wrapper that actually does file I/O. This makes it
trivial to test the parsing without having to *physically* create files
on disk...
...and then my boss ordered me to munge the two together and write tests
that actually create (and then delete) files on disk. Sometimes I feel
my talents are totally wasted...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Enterprise Java Beans... LMAO!
>
> good to know I brought to your attention this decade-old tech
You know, I once started reading about WTF a "bean" actually is...
...a decade later, I *still* have no idea! I hypothesise that it's a
software design fad.
(It still amuses me how every five years or so the industry oscillates
between thinking that fat clients are best, and then thinking that thin
clients are best. In truth, both have advantages. But at any given
moment, the industry claims that one is "the future" and the other is
"legacy"...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/11/2013 23:19, Orchid Win7 v1 nous fit lire :
>>> Enterprise Java Beans... LMAO!
>>
>> good to know I brought to your attention this decade-old tech
>
> You know, I once started reading about WTF a "bean" actually is...
>
> ...a decade later, I *still* have no idea! I hypothesise that it's a
> software design fad.
>
> (It still amuses me how every five years or so the industry oscillates
> between thinking that fat clients are best, and then thinking that thin
> clients are best. In truth, both have advantages. But at any given
> moment, the industry claims that one is "the future" and the other is
> "legacy"...)
they have the same oscillations about their market: "we need to extend
the applications of our product(s) to new domain"..."we need concentrate
on our heart-skill and drop the border for better competitivity"...
The military had it easier: To Do and Undo is still a work, do not
execute an order before the counter-order has arrived.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> *mumble something about the company not actually having any defined
>> direction*
>
> Certainly someone must have an idea what the company does.
Remember that "the company" consists of less than 10 humans [decimal].
When a company is that tiny, they don't necessarily have a grand
"corporate vision" laid out in meticulous detail.
From what I can gather, the business owner's plan is to make a product
that does everything for everybody. Every time a customer mentions
something the product doesn't do, we must immediately implement that
feature.
I presume I don't need to explain why this is a flawed approach?
> You're very
> secretive about even where you work, so it's kinda difficult to provide
> specific information.
>
> What market does the company serve? Who are its competitors?
Put simply, we make stuff used by several foreign governments, and if
you want to know exactly what it does, you're going to need security
clearance.
Not joking.
That probably makes it sound *far* more exciting than it actually is.
But obviously I'm not going to sit here and talk about it on some random
Internet forum that anybody can read.
What I can tell you is this: There are only so many governments in the
world. So our market is small, and competing products number dozens
rather than thousands or something.
>> Thing is, if I say "I wrote some code", that's too short. And if I
>> describe everything I implemented - even just the noteworthy stuff -
>> that's *way* too long.
>
> There's a middle ground. "I wrote code that does 'x'" - as a summary,
> not a detailed description.
Well, this year I wrote code for about 25 different small tasks. A list
of 25 items seems a little excessive though...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Nov 2013 22:49:36 +0000, Orchid Win7 v1 wrote:
>>> *mumble something about the company not actually having any defined
>>> direction*
>>
>> Certainly someone must have an idea what the company does.
>
> Remember that "the company" consists of less than 10 humans [decimal].
> When a company is that tiny, they don't necessarily have a grand
> "corporate vision" laid out in meticulous detail.
Well, I'm assuming it's not a lawnmowing business, or a garden centre, or
an aircraft manufacturer.
So the product must do *something* specific.
> From what I can gather, the business owner's plan is to make a product
> that does everything for everybody. Every time a customer mentions
> something the product doesn't do, we must immediately implement that
> feature.
So, I take it that the product is an accounting product that does asset
tracking, maintenance management planning, fleet management, building
security access, general spreadsheet/word processing/presentation tools,
car diagnostics, virus scanning, automated teller machine management,
city planning, scheduling of police department rosters, web hosting,
Linux kernel tuning, ... - all of that?
> I presume I don't need to explain why this is a flawed approach?
I presume I don't need to go on with my previous paragraph, no? There is
*some* sort of scope. I've worked with companies that don't have a
"grand corporate vision laid out in meticulous detail" but it was still
possible to say "here's what we do" or "here's what our goals are".
So that's the starting point. You know you don't mow lawns for pay. You
know you write software that does *something*. Within the scope of that
"something," it may be broadly defined, but the scope isn't going to be
"do everything software could possibly do for anyone anywhere".
>> You're very secretive about even where you work, so it's kinda
>> difficult to provide specific information.
>>
>> What market does the company serve? Who are its competitors?
>
> Put simply, we make stuff used by several foreign governments, and if
> you want to know exactly what it does, you're going to need security
> clearance.
>
> Not joking.
So, I'm going to assume it's not lawn mower scheduling. :)
> That probably makes it sound *far* more exciting than it actually is.
> But obviously I'm not going to sit here and talk about it on some random
> Internet forum that anybody can read.
>
> What I can tell you is this: There are only so many governments in the
> world. So our market is small, and competing products number dozens
> rather than thousands or something.
That's a fair thing to say. So, you know that you compete in a certain
market. That defines the scope of what you are working on. You probably
don't work on it all, so limit what you include in your self-assessment
to what the specific code you wrote does for the product and what it
brings to the product. Don't say things like "if I didn't do it, someone
else would" because the point of the self-assessment is that /you did
it/. It wasn't someone else.
>>> Thing is, if I say "I wrote some code", that's too short. And if I
>>> describe everything I implemented - even just the noteworthy stuff -
>>> that's *way* too long.
>>
>> There's a middle ground. "I wrote code that does 'x'" - as a summary,
>> not a detailed description.
>
> Well, this year I wrote code for about 25 different small tasks. A list
> of 25 items seems a little excessive though...
Start with the list of 25 items, then work with your manager to classify
the items in more broad categories if necessary.
I had performance reviews/self assessments/goals that included maybe 4 or
5 main categories, each with a half dozen items under them. That's not
unusual.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Nov 2013 22:14:00 +0000, Orchid Win7 v1 wrote:
> If it were noticed that I was only pretending to work, I'd probably be
> fired on the spot. That doesn't mean that my work is critical to meeting
> deadlines - it's just that, why would you pay somebody to do nothing?
They actually hired you to do a job, and you're doing it - so as a self-
assessment, you need to talk about how you're doing the job they're
paying you to do.
You're still relatively new to the organization, so it's entirely
possible that your tasks to date haven't been mission-critical deadline
items, but you need to talk about them in the assessment, certainly.
Getting things done earns you more responsibility, more visibility, and
ultimately (it's generally hoped) more pay.
So look at this another way - they interviewed you, hired you, and seem
to be happy with the job you're doing, right? So don't tell them they're
stupid by saying that what you do doesn't matter.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
