|
Engineers are NOT good writers. Period.
Usually the problem is lack of documentation; it simply isn't there.
When it is, it is frequently very poorly organized, as seen from a user's point of view:
Sometimes so 'structured' in an over-academic sense that until you have all the developer's abstractions into your head, it is impossible to guess where the concrete detail is found.
Sometimes, the engineer spends lots of time & space on explaining the last, super-fancy features, skipping everything about the fundamental mechanisms.
Sometimes, the documentation writer comes from some other environment, assuming that all readers share the same background so he can limit himself to the changes, say from Windows Forms to WPF.
Or, a printed book of 870 pages, neatly organized into 17 well defined chapter subjects - yet the author takes for granted that when you look up something on page 672, you have understood and memorized every single detail in the preceeding 671 pages.
Or, for online documentation, you are in a maze of twisting little passages, all alike, following links from the API to the class of the argument to the constructor to the class of the constructor alternativ list to a specific constructor to the enum definition to ...
Of course there are search functions. But we have had years of "my hit list is bigger than your hit list", so while fourteen million hits is bound to give a recall of very close to 100%, the precision is a small fraction of a percent. Actually, filtering functions were better ten years ago than they are today, but hit lists are magnitudes larger.
As long as you work only with a limited set high-fashion tools that you see in every project every day, and you need not know how things work, only how to invoke them, you can learn by heart most that you need. The problem lies in those things you use rarely, and neither time nor money allows you to go to a two week training course, yet you need to undertand it thoroughly. Then you may spend so much time with books and online searching that you may end up thinking that the two week training course might have been a good idea anyway, because documentation by itself is useless...
|
|
|
|
|
I had a bad experience of build breaking my web app, while I was migrating my ASP.NET Core 1.1 based web app to a newer experience, with ASP.NET Core 2.0 app.
Those 2 days and 1 night were tough for me. So, yes, I can cope with quite everything but with a tool that itself is breaking the build. That. Is. Painful.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
'Incomplete requirements' are great productivity killers.
Associated with the missing details that comes with a dropper, you can end up solving the same problem 5 or more times. And as we are lucky, each missing detail makes the previous solution unusable.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Then again, I remember an old story, I believe it was published in Datamation:
The writer's company had been rewarded a US Defence contract, and he was assigned the task of identifying every explicit requirement in the contract text. This is long ago, so he copied each individual requirement to a 4-by-6 card so they could be ordered and grouped freely. When almost half the contract period had expired and he told the project mananger for the third time that he needed another supply of cards, and a second box to hold them, the project manager broke off that activity: What we haven't discovered yet, they won't detect as not fullfilled!
They did complete the project in time. At the review meetings nearing the end of the project, the Defence people did point out a few details the implementors had overlooked, and they came in place. But according to the storyteller, several points that were indicated in the requirements as essential was never implmented, and noone had ever asked for them later.
Also, when I was a student, one of our books in systems engineering had a list of "Things that may delay your project". The list contained both "The customer in inexperienced with data processing" and "The customer is experienced with data processing". I guess that US Defence story is an example of the latter.
|
|
|
|
|
|
Why not just block his number and call him on the drive home?
|
|
|
|
|
Even better... block his (OP) number in his (brother-in-law) phone
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Grow to stuff between the legs and put him in his place. Stop being a people pleaser. No calls while you're at work. This is a boundary I had to put up for my wife. Worst thing is when you're in a meeting and have an audience and you're busy talking to the audience and you feel your phone vibrating in you're pocket.
|
|
|
|
|
So....grow a pair and tell him to stop calling.
|
|
|
|
|
|
The wrong tool for every job.
|
|
|
|
|
Boring people, unproductive regulation and rules.
I need bleaching for those to br cleaned.
Scott from Maine
|
|
|
|
|
Not just environment but the office culture is important to drive productivity. A minimum interruption, quite, relax dressing code and flex time work environment is ideal.
|
|
|
|
|
Since I work on projects I want if I reach a difficult spot it's hard to stay motivated to finish, or find a solution. Sometimes!
Someone's therapist knows all about you!
|
|
|
|
|
I used to know experts[^] for that problem. I even got to do some motivating myself.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
I've had dealing with those same types when I was younger and it wasn't a pleasant experience.
I guess I must have really pissed them off cause hey sent me to a jungle where people shot at me and liked me even less. Go figure!
Someone's therapist knows all about you!
|
|
|
|
|
Mike Hankey wrote: hey sent me to a jungle where people shot at me and liked me even less Don't envy you for that. For historical reasons we did not participate in that kind of actions, but in 1991 I also had to pack and fly eastwards.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
The unending meetings with a 15 minute gap between them.
|
|
|
|
|
^This. It should be one of the options listed there.
|
|
|
|
|
What? You don't want 15 minutes between them
We are given laptops where I work now, and it is not uncommon to see most people in the meeting ignoring the meeting while working on something else...
|
|
|
|
|
Agreed! I'm currently scheduled for eight meetings that occur every week. One is an hour, the rest are 30 minutes. They're spread out over Tuesday and Wednesday, with the end result that those days my productivity is very low.
Software Zen: delete this;
|
|
|
|
|
Yep, beginning with the morning stand-up.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Don't about the rest of you, but I hate 15 minutes stand-up every morning. I hated scrum with a passion.
|
|
|
|
|
The only usefulness I've ever gotten from Agile is the formal breaking down of a project into smaller pieces. But then, every intelligent programmer did that without needing a formal methodology to require it. Otherwise Agile is nothing more than a tool of little benefit to programmers, but loved by project managers.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Based on my experience a project attempting agile software development will always be a mess if they have a project manager. I've also noticed that without a project manager you end up with those lazy developers only delivering half the project and not billing the client the full amount.
|
|
|
|