|
Nagy Vilmos wrote: giggles What a great name for a programming language!
From where can I download the compiler?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
... may not make sense even to yourself at a later time.
I like to think that
- comments above a method/class/property tell you what is its purpose or goal, and any implied contract on the state of input parameters.
- comments in the method tell you why you are doing something, with emphasis on warnings, subtle issues, or warnings about dragons
- the code should read like a story, but it is only telling you how you are doing whatever you are trying to accomplish, not the reason for it.
You write code for the programmers that come after you to fix/modify the functionality/performance of your code. It might be you next week, next month, 5 years from now.
Computers read binary.
|
|
|
|
|
W∴ Balboos wrote: Not writing comments, under the presumption that the coding is so clear that it explains itself, falls into the category of debugging your own applications.
Ah! You've caught me! I've been the only developer working in our code for most of the last 15 years, and comments are few and far between. In my mind, the code is self-explanatory and I have no problem (usually) of understanding it.
Now, we are hiring an intern for the summer who will be converting this legacy code into .NET and I'm now cringing at what probably will be fairly difficult for a newbie to read and comprehend. I'm hoping that my descriptive variable/method/function names read well enough for him to make sense of it, otherwise, I'm sure to be explaining it. I'll also need to lay down the rules for commenting in the new development.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Indeed. How often I have seen some more or less readable code which actually told me what is being done, but not a single clue why it's being done and what it is supposed to accomplish.
Only a master of the obvious writes comments that tell us what is going on.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
How could you all forget:
C IDIOT
(FORTRAN)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
So I have to make a little something for a customer.
Basically they want to name a stored procedure and all of its parameters in the database after which a user can select a procedure in the application, fill in values for the parameters and have the data shown in a grid.
So we have dynamic types (for parameters) with dynamic default values, dynamic forms, dynamic results, etc.
Still, no problem. So I gave a estimate of three to four days for the entire thing.
I get an email from the customer asking me to explain why it would take so long. His experience taught him it would take two days max.
So I explained I need to have a little room for issues (I'm working in the customer's software, with third party tools, that aren't completely known to me), that I need to test, and that working with all that dynamic data can be tricky.
I get another email back "In my experience working on this kind of solution isn't tricky at all!"
So why have me do it then?
I already ran into an issue and his proposed solution wasn't going to work. That's half a day on 'issues' already!
|
|
|
|
|
You have forgotten management rule 47:- everything I don't know how to do is easy
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
Sounds like a Dilbert thing
|
|
|
|
|
doesn't make it untrue
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
Bergholt Stuttley Johnson wrote: doesn't make that's why it's untrue FTFY
|
|
|
|
|
There is indeed a comic about just that, but I can't seem to find it. Take this instead:
http://dilbert.com/strip/2013-10-19[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
If he is more experienced, he should do it himself.
Sander Rossel wrote: His experience taught him it would take two days max. Based on prior observations, I'd say he is bluffing in order to get the price down.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yeah, its tempting to turn around and say "I cannot match that timescale and understand you are taking you business elsewhere"
if only I had the courage
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
It's not about courage, it's about the need for the job... if you don't need it too much, then you have a more dominant position in which you can press a little bit more, if you need it desperately then you are screwed.
I remember time ago one guy that told me: "I have this amount of money to spend in the programming of 4 robot cells but I don't know exactly what has to be done".
It would have been a nice amount of money if the job would have lasted for 6 or 7 months, but without knowing what was involved, and knowing the amount of available time was almost a year I decided to let it go.
Customers some times...
|
|
|
|
|
Eddy Vluggen wrote: I'd say he is bluffing in order to get the price down Maybe. He should pick his bluffs more carefully then. He just told a coworker he wasn't a developer.
A non-developer bluffing to an experienced developer about the time something should take...
|
|
|
|
|
Sander Rossel wrote: A non-developer bluffing to an experienced developer about the time something should take... They're called "salesmen", "manager" or "CEO".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I've heard epic tales of their ignorance, yet now I've met one myself I'm still surprised
|
|
|
|
|
But... I get this sort of sh*t all the time, a manager who used to be a developer 25 years ago, in VB, concludes a meeting by saying, oh that should take about x days/weeks/months so I want it delivered in x-10%.
3 days later will also give you another project to complete in parallel, no change to the deadline!.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
It's absurd that logic and reasoning seem to be the opposite of one's power...
|
|
|
|
|
Actually said manager is brilliant, just not at estimating development resources, or managing minions. He manages senior management rather well!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You do know how they get salesmen?
http://dilbert.com/strip/2006-07-29[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
You have obviously not met a "Project Manager" before, this is their default position, they then move to "This only took x days last time you did it so you should be able to it quicker this time"
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
I would suggest your response to him might be "You have not enough experience".
|
|
|
|