5 things I learnt at Amazon
It’s been a exhilarating four months at Amazon, or atleast it will be in another eight days!
Coming fresh out of college, I learnt a lot about the difference between being just a programmer and a software development engineer. A programmer is someone who just codes what you tell him to; a code monkey, so to say. But a software development engineer is “a biological machine that automatically converts coffee and beer into code”!
This big lesson apart, here are a few other things I learnt so far,
- Your 10K+ code with all it’s fancy architecture and flawless implementation is worth nothing if it’s not solving the business problem that it was needed for. Understand the context of the problem before jumping to conclusions.
- Sending your code review without proper comments is *much* worse than walking naked on the streets
- 5 minutes of extra thought at design time is 5 hours in dev time. Sketch up a rough design even if your writing a script.
- 1 hour into reading the fine manual is otherwise 10 in writing your own code.
- Using an unstable library is like shaving in the dark. You’re bound to cut yourself if you don’t know what you’re laying your hands on
At the end of the day, work is a lot of fun (and a lot of TT
). I find it hard to go home
Categories: Technology
So, you have tried both options of #2 out?
Not yet actually. But I came close to doing the first
And did u ever realise that these 5 things and many more were there in fine print (by one pressman) and in ppts (by one gopal) ????? And remember the way we ignored it ???
Putting it like this is a lot different from saying “The fourth level DFD of the user level design level diagram implemented by the software engineer should have its flow boundaries distinct”
Give it to the people in the way it makes sense to them, someone should have told someone( one pressman makes a good candidate)
#5 should not be a problem now that gillette(R) vectorplus(R) is out. They even have a money-back offer if you do get yourself cut in the dark.
@vijay dev
The prob then was that it was too theoretical and abstract, without specific do’s and dont’s and practical examples, and the effects of not following the principles.