Re: Programmers Nostrums
by tilly (Archbishop) on Nov 24, 2009 at 21:35 UTC
|
| [reply] |
Re: Programmers Nostrums
by planetscape (Chancellor) on Nov 24, 2009 at 21:15 UTC
|
From the "Lessons Learned" section of my journal:
The real problem is almost certainly not what the customer says it is.
Also:
Sullivan's Rules for Getting and Keeping Clients:
- Listen to your clients so that you understand their business needs
- Match leading-edge technology to the client's goals
- Explain in business terms how your solution will help the client meet goals
- Deliver on time and within budget
- Use a framework that helps ensure quality control
- Network with associates who can bring value to your projects
- Use your success stories to sell yourself to clients
- Keep your technical skills up to date through training
- Develop good verbal and written communication skills
- Share knowledge of IT trends with your clients
- Romeo, Jim: "The Fine Art of Getting and Keeping Clients." Contract Professional, Vol. 4, No. 7, March 2000, pp. 28
Source unknown:
Know your priorities. A computer that crashes constantly isn't as important as part of a network that has suddenly gone down.
Murphy's Law states if anything can go wrong, it will. Always be prepared for anything that might happen throughout the day. Keep a backup plan for everything.
Know how to deal with everything on your network. It's good advice to know how to do everything, from running the server to adding new hardware in a machine.
Use a team effort whenever possible. Things get done faster when you team up to work with your fellow IT peers.
Know your users. This helps you understand their wants and needs, and allows you to provide assistance to them much more easily.
Give extreme timeframes. If someone needs something done, tell him or her it will be done in a week, and hand it to them 3 days later.
From Tech Republic:
Develop and test a backup plan.
Schedule hardware upgrades during a known good environment.
Communication is key.
Walk away from a problem to take a deep breath, then return to the troubleshooting basics. We were so intent on fixing the problem that we neglected to first identify the problem.
Never anticipate that you can have a smooth day, get off on time, and enjoy hours of play online with Rogue Spear.
From: Just another smooth-running day in IT . . .NOT! (original link - still works, to my surprise)
| [reply] |
|
Give extreme timeframes. If someone needs something done, tell him or her it will be done in a week, and hand it to them 3 days later.
I got told about this one by a senior colleague (sp?), and it is the best lesson i ever learnt: People are pleased when you finish 'early' and not angry when (inevitably) your timeframe was over-ambitious and things take longer than you expect! Brilliant.
It also helps combat the extreme under-estimation of timeframes by non-programmers: "All you have to do is click a button! Why will this take so long!?" "Well, first i have to build the button..."
Just a something something...
| [reply] |
|
| [reply] |
|
|
Re: Programmers Nostrums
by ww (Archbishop) on Nov 24, 2009 at 19:54 UTC
|
The last bug is fixed when the last user abandons the code. | [reply] |
Re: Programmers Nostrums
by kyle (Abbot) on Nov 24, 2009 at 21:08 UTC
|
Every program contains at least one bug. Every program can be shortened by at least one instruction. Therefore, by induction, every program can be reduced to one instruction, which doesn't work.
| [reply] |
Re: Programmers Nostrums
by tweetiepooh (Hermit) on Nov 24, 2009 at 17:11 UTC
|
Not my own but
- you can have it fast, cheap, well done - pick two
- work to the documentation
| [reply] |
|
| [reply] |
Re: Programmers Nostrums
by ambrus (Abbot) on Nov 24, 2009 at 21:46 UTC
|
Use a table, even if most of the entries are the same/empty, it makes your logic simpler and computers like them (remember this was when you sweated over every byte your code used).
No, that was back when the CPU would run on the same frequency as the RAM so you didn't have to think about caching. Nowadays looking up something in a large table can be expensive because accessing RAM is slow, but on the other hand conditional jumps can be expensive too because of prefetching and decoding, so figuring out what takes more time is much more complicated. (But at least there's still good documentation (eg.) so if you really take the time to RTFM then you can make an educated guess.)
| [reply] |
Re: Programmers Nostrums
by dragonquest (Beadle) on Nov 25, 2009 at 09:57 UTC
|
| [reply] |
|
Meta request: Is it possible to derive a statistic for a given monk, that shows how many of their original, or first reply posts, contain a (significant) code section?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
| [reply] |
|
Re: Programmers Nostrums
by Jenda (Abbot) on Nov 25, 2009 at 10:33 UTC
|
Formal process doesn't improve code quality. It just increases the delays and annoys the developers.
Having each and every code release approved by ten people that know nothing about the code changes and would not understand the code even if they tried, doesn't increase security. Just the feel of it.
Making changes on production is dangerous. As such it should be done by someone who understands the application and the changes being released. Do you really think a separate "release engineer team" who is in charge of releases for all the company's aplication, blindly following a "release plan" is a good idea?
A small example of code that got through a massive formal process and had been on prod for some time now:
sub syb_executeQuerySingleValue {
my $query = shift;
my $dbh = shift;
my $val = undef;
$recordSize = executeQuerySingleValue($query,$dbh) ;
return $recordSize ;
}
A little gem isn't it? But it takes about three hours to fill in all the fields in all the request/issue/bug/whatever tracknig systems and write all the required documents to eventualy after several weeks get a five line change in a single script to production.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] [d/l] |
Re: Programmers Nostrums
by educated_foo (Vicar) on Nov 26, 2009 at 07:30 UTC
|
My dictionary says nostrum |ˈnɑstrəm|
(noun)
* a medicine, esp. one that is not considered effective, prepared by an unqualified person.
• a pet scheme or favorite remedy, esp. one for bringing about some social or political reform or improvement.
Programmers have plenty of meaningless rituals and political slogans; you should always question them. | [reply] |
Re: Programmers Nostrums
by Narveson (Chaplain) on Nov 24, 2009 at 18:47 UTC
|
A link to Perl Best Practices.
Or if you're looking for things you could actually pin up on a notice board, how about copies of some of the Top Ten lists at the back of the book?
| [reply] |
Re: Programmers Nostrums
by JavaFan (Canon) on Nov 25, 2009 at 12:08 UTC
|
common exit
I like my last, next, redo, return, die, exec, exit and goto-&* too much to go back to Pascal.
*Did I miss any?
| [reply] |
|
| [reply] [d/l] |
|
I considered that, but if %SIG breaks "common exit", then any subroutine or function call would, wouldn't? Assuming the handler doesn't terminate the process, a signal handler returns to the point where the block was left, so it's not more an exit that calling any other sub.
| [reply] |