On Wed, Nov 2, 2011 at 10:31 PM, kracekumar ramaraju < kracethekingma...@gmail.com> wrote:
> > True... to some extent. Like just about anything else, you have to choose > > wisely. > > My four years at Kanbay (now CapGemini) taught me a lot of lessons in > > organization, management as well as presentation. > > > > Well my question is how much did you learn about programming, api > design, Unit testing, algo design Don't get me wrong, I'm not discounting engineering skills; we're all on the same side there. What I was hinting at above is that if you get lucky and get good managers at a mid-to-large co, you have the opportunity to learn how organization in the large works, and that's an important skill too. That said, I should clarify, when I say, 'spend the first couple of years maintaining somebody else's crap code', I say that from personal experience. Maintaining something you didn't build teaches you a lot about the importance of building good readable, maintainable, malleable code. I know I write good code because I don't want people who end up maintaining it (myself included) to go through the agony I had to back then. That's probably one the biggest takeaways I have from back there; and that was what I was primarily pointing to. It usually turns out to be a bit of a trial by fire and you have to fight the urge to just get sh!t done. Not to mention the people around you who churn out bad code on a regular basis. But if you can battle through it, you'll have a better appreciation for these practices. I realize this is a little backwards, but then again I know it worked for me. YMMV. As for core engineering skills, programming, API design, algorithms, etc- I learned most of that on my own and guess I would have no matter where I was. But that's just me. We got a computer at home very early on, a trusty 386 way back in the early 90's and started off right then and never looked back. Arguably, Kanbay didn't really ^help^ on that front, but I did end up with a few good colleagues to bounce ideas off. But in my experience, this usually is something that has to come from within. Once you've established that the person has an innate need to better themselves there's a whole slew of resources out there at your disposal. Of course, having totally awesome programmers around you doesn't hurt (loosely translated from- helps a whole whopping bunch!) :) I'll concede the bit on testing here. I don't think I would ever have appreciated testing if it wasn't for my time at ThoughtWorks. > , agility Interestingly enough, I got my first lessons in agility from a client director at one of the projects at Kanbay. Although, we didn't call it agile or lean back then and he was quite the visionary, so I guess I got lucky again. :) how to distinguish good programmer from bad programmer. > There was a fairly simple heuristic some of us went with, a good programmer is simply someone *you* would like to learn from. I liked that so much, that I haven't really bothered to ponder that question much beyond that. Sorry If i am rude :) I promise to take offence ^only^ if you meant to be rude. ;) - d _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
