Abaddon wrote:
some tips from my experience, your mileage may vary

I think this is a fairly good list of programming lessons. I have a few comments though.

1. Kludges that we'll fix in the next release never get fixed in the next release...

Decius's Corollary: You're not going to have more funding when you are working on the next release.

3. it always costs more to do it later...

It doesn't matter how "right" it is if it never ships.

4. beware of anyone in a suit...

Unless they are a civil liberties lawyer.

14. never assume they have tested their code...

Abaddon's Corollary: All other programmers are out to get you.

Decius wrote:

3. it always costs more to do it later...

It doesn't matter how "right" it is if it never ships.

4. beware of anyone in a suit...

Unless they are a civil liberties lawyer.

14. never assume they have tested their code...

Abaddon's Corollary: All other programmers are out to get you.

no that last one was Rusty Russel, not me, I just repeat it alot cause its good advice...

I also agree about the it doesnt matter how right it is if it never ships, but I think part of the skill in being an engineer is to design something that you *can* ship in the time allotted that is still a "correct" sollution...this sometimes means scaling back what you're making, but whatever you make should never be "wrong"...if that makes any sense...

Abaddon wrote:

Decius wrote:

3. it always costs more to do it later...

It doesn't matter how "right" it is if it never ships.

4. beware of anyone in a suit...

Unless they are a civil liberties lawyer.

14. never assume they have tested their code...

Abaddon's Corollary: All other programmers are out to get you.

no that last one was Rusty Russel, not me, I just repeat it alot cause its good advice...

I also agree about the it doesnt matter how right it is if it never ships, but I think part of the skill in being an engineer is to design something that you *can* ship in the time allotted that is still a "correct" sollution...this sometimes means scaling back what you're making, but whatever you make should never be "wrong"...if that makes any sense...

But alas... the requirements change. Now, it is certainly the job of a good engineer to design and build a system in the time given that can adapt to changing requirements... but you still never get it quite right.

Jello wrote:

Abaddon wrote:

Decius wrote:

3. it always costs more to do it later...

It doesn't matter how "right" it is if it never ships.

4. beware of anyone in a suit...

Unless they are a civil liberties lawyer.

14. never assume they have tested their code...

Abaddon's Corollary: All other programmers are out to get you.

no that last one was Rusty Russel, not me, I just repeat it alot cause its good advice...

I also agree about the it doesnt matter how right it is if it never ships, but I think part of the skill in being an engineer is to design something that you *can* ship in the time allotted that is still a "correct" sollution...this sometimes means scaling back what you're making, but whatever you make should never be "wrong"...if that makes any sense...

But alas... the requirements change. Now, it is certainly the job of a good engineer to design and build a system in the time given that can adapt to changing requirements... but you still never get it quite right.

I think it is never quite what you want, but I disagree that its never a correct design, I think we're arguing over symatincs here, Im basically arguing that there should never be a kludge, never a section that you know is going to cause problems if they do the wrong thing, never a section that you know is just crap...

Abaddon wrote:

Jello wrote:

Abaddon wrote:

Decius wrote:

3. it always costs more to do it later...

It doesn't matter how "right" it is if it never ships.

4. beware of anyone in a suit...

Unless they are a civil liberties lawyer.

14. never assume they have tested their code...

Abaddon's Corollary: All other programmers are out to get you.

no that last one was Rusty Russel, not me, I just repeat it alot cause its good advice...

I also agree about the it doesnt matter how right it is if it never ships, but I think part of the skill in being an engineer is to design something that you *can* ship in the time allotted that is still a "correct" sollution...this sometimes means scaling back what you're making, but whatever you make should never be "wrong"...if that makes any sense...

But alas... the requirements change. Now, it is certainly the job of a good engineer to design and build a system in the time given that can adapt to changing requirements... but you still never get it quite right.

I think it is never quite what you want, but I disagree that its never a correct design, I think we're arguing over symatincs here, Im basically arguing that there should never be a kludge, never a section that you know is going to cause problems if they do the wrong thing, never a section that you know is just crap...

Sometimes... anything other than a kludge would require more time than you have. I think in some ways it is unavoidable to have to do major revisions to software, in practice. When end-users are involved, there are eventually always un-forseen requirements that require re-architecting. Good design can make these major revamps happen less frequently.

This is happening to me, this week. So... yeah.

Jello wrote:
Sometimes... anything other than a kludge would require more time than you have. I think in some ways it is unavoidable to have to do major revisions to software, in practice. When end-users are involved, there are eventually always un-forseen requirements that require re-architecting. Good design can make these major revamps happen less frequently.

This is happening to me, this week. So... yeah.

I'll agree that from time to time we're all forced to compromise and break a rule...but with good planning rearchitectures shouldnt sneak up on you, and the last minute kludges you might be forced to do are the extreme exception, I make it a rule to never do it (a rule which does get broken on rare occations) because most programmers think those rare exceptions come much more often than they should...in practice a well designed system will accept a lot of change and rearchitecture without needing kludges...

so basically because I have little faith in most programmers I make it a rule to never kludge my way to the finish line on any project...the few good programmers out there can be trusted to know when to break this rule, the rest cant...

29. an engineering manager's job is to keep his engineers sheltered from politics or any other "real world" consideration, so all they have to think about is coding...

This is the basis for the litmus test all engineering managers should be subject to... If they don't understand this concept, off with their heads.

And I say this as someone who figured it out while managing... There is no way to emphasize how critical this is.

some tips from my experience, your mileage may vary

1. Kludges that we'll fix in the next release never get fixed in the next release...

2. if you dont do it right now, you (or some poor bastard that replaces you) will have to do it right later...

3. it always costs more to do it later...

4. beware of anyone in a suit...

5. if you don't talk to your customers to see what will make them happy, then sooner or later someone else will...

6. Sales guys can be powerful allies for interoffice BS, but if you make yourself too available they will never leave you alone...

7. Management has no idea what the customer wants...

8. Engineering has even less idea what the customer wants...

9. Assume every engineer you work with is an idiot, try not to let on that you know...if you find engineers that are obviously not idiots, find a way to keep them...

10. Never outsource your core competency...

11. Lazyness and incompetence are contagious...

12. no-one cares if you read wikipedia all day every day if you get your work done on time...

13. your code is not finished until you've tested it...

14. never assume they have tested their code...

15. engineers that think lack of documentation is job security should be fired sooner rather than later (otherwise you'll make them right)...

16. Contrary to popular belief, third party libraries reduce portability of your code...

17. Engineers thinking something is "cool" is not a business case...

18. Engineerings job is to say yes, no matter how stupid management's requests are...good engineers find ways to say yes that spotlight their intelligence and managements stupidity...(e.g. if they ask you to turn lead into gold, tell them you will if they allocate a few trillian dollars and a fusion reactor)...

19. the night before its due is probably not the best time to start integrating your code in a large project...

20. you can be really good at your job, and a dick, or you can be so so and your job and a really nice guy...you cannot be a dick who is bad at his job...

21. Time estimation is really hard...it will take longer than you think it will...

22. demonstrating that your compeditors suck isn't enough to get anyone to buy your product...

23. don't ship anything you're not proud of...

24. your code will be used in ways you never thought of...plan accordingly...

25. if you can't settle on one way of doing something, do it both ways and make it a configurable option...

26. don't ever have arbitrary limitations, or if you do, hide them better (e.g. "max users 256"...hmmmm?)...

27. strive to make a really good 1.0, then move on to other, more fun projects...you'll still get all the glory for that first project, but you won't have to do the work anymore...

28. in general, meetings are the opposite of getting things done...

29. an engineering manager's job is... [ Read More (0.3k in body) ]