Name: Anonymous 2010-07-18 9:35
I'm a /prog/rider who's been doing actual ENTERPRISE development for about a year.
Stuff I realize now:
* The main incentive for properly separating application layers and making sure your code doesn't have anything hard coded in it isn't really robustness, flexibility, scalability, etc. It's protecting yourself from stupid clients. Clients have a hard time explaining themselves, and they often don't know what they really want or need. They might change their minds at the last moment, or believe that some change they forgot to mention is "tiny". Enterprise-grade software is client-proof software.
* Enterprise software must be practical, not smart. Sometimes the client will love you for creating a butt-ugly UI that allows him to shove all the data in a single window, and disdain you for building something that is usable, pretty, and elegant.
* The greatest danger an enterprise developer might face is maintaining old code. All efforts should be made to write code that's easy to maintain. This has a very sad consequence: you have to dumb it down. Nobody knows functional programming; avoid lambda expressions, lists, filter, map, reduce. Keep it simple. You don't have to comment fucking everything, but at least give a general idea of WTF you're doing in complex pieces and give your variables and methods names that make sense. Verbosity goes together with algorithmical complexity: if you're writing something simple, write concise code; if you're writing something intricate, make it verbose. Forget language-specific tricks.
* Don't write anything serious right before your vacation.
* Always write a document describing the general architecture of your software. Stick to it. Don't be a dickhead, don't make yourself irreplaceable. Think about the people who'll do emergency maintenance on your application.
* Women are terrible coders. Especially the pretty ones. Always revise their shit.
* Bosses and software "engineers" are mostly useless unless they can write good code. I'm not saying they should: I mean this is how you test them for decency. If you're unsure about your boss, ask him about his past professional life, what projects he worked on, etc. If he's been a programmer in the past, great. If he hasn't, be careful. Watch out for stupid decisions that might impact your work. Always keep that in mind.
* Java development is a pain in the ass, but everything is free. .NET development is not a pain in the ass, but everything costs money.
* Good PHP code is impossible to write. If you think you wrote good PHP code, you're wrong.
* Always keep friendly relationships with the network, server and database guys. They mostly hate developers, and they can and will fuck you over.
Stuff I realize now:
* The main incentive for properly separating application layers and making sure your code doesn't have anything hard coded in it isn't really robustness, flexibility, scalability, etc. It's protecting yourself from stupid clients. Clients have a hard time explaining themselves, and they often don't know what they really want or need. They might change their minds at the last moment, or believe that some change they forgot to mention is "tiny". Enterprise-grade software is client-proof software.
* Enterprise software must be practical, not smart. Sometimes the client will love you for creating a butt-ugly UI that allows him to shove all the data in a single window, and disdain you for building something that is usable, pretty, and elegant.
* The greatest danger an enterprise developer might face is maintaining old code. All efforts should be made to write code that's easy to maintain. This has a very sad consequence: you have to dumb it down. Nobody knows functional programming; avoid lambda expressions, lists, filter, map, reduce. Keep it simple. You don't have to comment fucking everything, but at least give a general idea of WTF you're doing in complex pieces and give your variables and methods names that make sense. Verbosity goes together with algorithmical complexity: if you're writing something simple, write concise code; if you're writing something intricate, make it verbose. Forget language-specific tricks.
* Don't write anything serious right before your vacation.
* Always write a document describing the general architecture of your software. Stick to it. Don't be a dickhead, don't make yourself irreplaceable. Think about the people who'll do emergency maintenance on your application.
* Women are terrible coders. Especially the pretty ones. Always revise their shit.
* Bosses and software "engineers" are mostly useless unless they can write good code. I'm not saying they should: I mean this is how you test them for decency. If you're unsure about your boss, ask him about his past professional life, what projects he worked on, etc. If he's been a programmer in the past, great. If he hasn't, be careful. Watch out for stupid decisions that might impact your work. Always keep that in mind.
* Java development is a pain in the ass, but everything is free. .NET development is not a pain in the ass, but everything costs money.
* Good PHP code is impossible to write. If you think you wrote good PHP code, you're wrong.
* Always keep friendly relationships with the network, server and database guys. They mostly hate developers, and they can and will fuck you over.