|
Writing meaningful surveys...
|
|
|
|
|
I had 5 for easy 1 for hard. Oops. I had a couple of 3's.
|
|
|
|
|
Fair to say you find (1) hard then
Where is the "joke" type??
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
|
Yes and no. I'm usually good at finding a happy medium when need be.
|
|
|
|
|
and useless. Let's see the counts for each option!
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
+1
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.
|
|
|
|
|
|
|
I hate writing documentation;
I find it very difficult to write documentation explaining processes or steps to do something.
For example, I have to write some sort of documentation about our installer, and I can't write the introduction; other than "trust me it works".
I'd rather be phishing!
|
|
|
|
|
One of the terrible aspects of documentation - in particular if you do it after the design has been finalized, og even worse: after most of the code has been written - is that you realize how things should have been done, but were not.
Internal system documentation, or user documentation, they are all alike. Documentation to the sales people, too: They all make you say "Sh*t, why did we do it that way?
When I make something for myself on my home PC, I always start out by writing down for myself how I want the program to behave, a "user documentation". Over a period of a couple weeks, I change it back and forth, new ideas pop up, others are thrashed. (Walking to work, seven kilometers roundtrip, gives you more than an hour a day to ponder needs and solutions.) Gradually, I start sketching data structures, match them to the user needs, and making sure they reflect the application concepts as viewed by a user. Gradually, data structure descriptions migrate from informal English into code formalisms, and I start writing code... But developing along those lines is not possible at my workplace. In principle, yes, but in practice, we never have the time. Which may be extremely costly in terms of time, in the long run.
|
|
|
|
|
With you 100% on the documentation...eliminating the tech-speak makes it a mundane and thankless chore
|
|
|
|
|
Writing documentation isn't so hard. Keeping it up to date is a massive headache!
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
PIEBALDconslt is Absolutely right.[^]
I picked one as "Very Easy" - because I never do it. How many other answers are junk like that?
Survey results are thus worse than useless as they're potentially misleading.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
If you don't do it, you don't know how difficult it is.
I have never written a unit test and I have no plans to -- in fact, it's possible that the system I need to use if I ever do hasn't been created yet!
|
|
|
|
|
Can be super frustrating if they are finding it difficult to grasp.
|
|
|
|
|
then the tech, code, or requirements - IMHO.
|
|
|
|
|
pay attention to separate social and technical issues. Often people mix that.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
... as I am in the lucky situation, that we do reviews, have good and manageable coding guidelines in place, which are _respected by each and every team member_.
So at least, from a ground structure of the solutions/project folders, naming of classes an members, obeying to patterns (events, singletons, factory, etc) we all find code that looks "close to our own code".
We even have code formatting rules in place through android/visual studio settings and all files get "Format File" auto-formatted by there rules, so there is no "member A uses 2-blanks for intendation while others use one tab and the next uses 3-character-tab".
Only the iOS/Apple crew falls out of this scheme as objective-c and xcode are a seperated universe. but ios coding is done through pair programming over large time frames, so each of the devs knows the entire code anyway - they found their way too.
Users... USERS are a problem
|
|
|
|
|
Quote: have good and manageable coding guidelines in place, which are _respected by each and every team member_ Is that really so?
'Good and manageable' means to some people to invent countless rules how to write something and to zealously amend new rules until every corner case is covered. That may be very manageable ( == easy to check), but does nothing much to avoid the real risks in the code. As if pretty writing and formatting would magically make all other problems go away.
And then there are the others who politely play along, because they know what kind of holy war would follow if they questioned the use of these things openly.
|
|
|
|
|
No, it's the matter whether a dev want to "push his own personal style and personality" into the code or if the team agrees to find a uniform way of doing things and stand the personal "but I do it this way!" back.
There are plenty of microsoft guidelines for .net coding, including several patterns, we have code analysis active, warnings are errors and at least the main pitfalls seen through many of the microsoft coding rules are avoided in our programs. yes we have zero warning production builds with code analysis active.
And NO, this is of course not the way to avoid bugs or problems. but that is not the topic here. the topic is "other people's code" and not "how can coding guidelines help you to avoid bugs".
and beside that we just agreed on some schemas and how to's...
it works.
|
|
|
|
|
That's good. I have seen it a few times that everything revolved around more and more rules and enforcing them. Code quality, in every possible sense, was secondary as long as the rules were observed. What a waste of time and work.
|
|
|
|
|
Agreed. I have been once in such a company that put more energy in enforcing their own rules (that often collided with publicly known how-to's than in working code.
Coding guidelines can be a huge waste of time, if done wrong. We agreed on day one, to take the microsoft rules and put our personal thoughts in the second row.
And you know what? Many of us fully agree in the meantime, that they "increased their skills" since the code analysis is in place - as some of the warnings really show hard-to-track-bugs if the subject of the warning comes true.
Our most beloved warning is the "call of a virtual method in the constructor call-chain". We thought about it and it was hard to understand, what microsoft means with that warning. we google'd a bit and found some cases where this indeed can lead to a horrific bug. this is one of the key warnings, where devs felt, that they advanced.
|
|
|
|
|
Wait 'till you inherit a source project from a college intern. Rewrite the entire project from scratch probably faster than trying to float it.
I have no problem maintaining team member's code.
|
|
|
|
|
Depends on who that someone else is, but overall it's absolute horror
I'm quite good with users though, I must be one of few.
My employers even said it in a performance review I had at my last job where I had a lot of customer contact, "You are really very good with customers, they pretty much love you."
Unfortunately, that went on "...We can't say the same about your colleagues"
|
|
|
|
|
Sander Rossel wrote: Depends on who that someone else is, but overall it's absolute horror So you are one of those lone cowboy programmers who can't work together with others?
|
|
|
|