A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I consider myself a pretty competent developer, but I'm struggling to go from "good to great".
I find it difficult to learn the latest tools, skills, and techniques when I can do things the way I have always done them. The code may be mediocre POOP (Procedural Object-Oriented Programming) code, but I'm known for delivering applications on time that work and meet the customers' requirements.
How do you further your skills? Do you set aside some time each week stictly for learning and skills development? Do you build in learning and experimentation time in your estimates? How do you justify this when there is an endless queue of work to be done?
This has been a constant struggle for me. I always feel that if I'm spending time learning and experimenting instead of delivering results, I'm doing the customer a disservice. Maybe it's just laziness.
Friday, August 18, 2006
I am right there with you....At times, I know the code is POOP but I just cannot pull back far enough to get the abstract view of it. On skill development, I get burned out coding about every four weeks (side job) and spend the time catching up on the reading. Usually how to code books or web based skill development. I really want to take some of the formal training classes and see how much they help me, as I am mostly self taught. Does anybody have any thoughts on the .NET training classes offered by various institutions? On the other hand, for the MicroISV market, better (ie, truly OO and very abstracted) can be the enemy of good enough for the client....
Step back and realize that if you are always dedicating 100% of your time on getting all the stuff done (and therefore not spending any time on improving your L33t 5k!llZ) you are eventually going to not be able to do the work your employers/customers/clients want done (in the new next best language/platform) and then you are going to put yourself on the street or on a forum complaining about .Net and how you can do anything with VB6.
"If you are not getting better, you are getting worse"
The literature says to become an expery you to continually set goals a little above your skill level. So I don't think you can do it in big chunks at other times. You need to somehow integrate the learning into your daily work even if you feel you will be a little less productive.
Over time your total productivity will increase even though at any time you feel like you are beeing less productive because you are feeling challenged.
son of parnas
Friday, August 18, 2006
D is correct. IT is all about change, this is a fact. What one needs to remember is that the last successful solution is not the panacea of all future solutions. This goes for languages, platforms, technologies, "paradigms", anything really.
Learn a static compiled language
Learn a dynamic scripting language
Learn a functional language
It matters not what languages because they all serve different purposes and arrive at results differently. You will be much more "brilliant" in your field knowing three different languages than knowing three of the same languages.
Learn about computers, networks, and protocols.
Remember that todays API is tomorrows relic - don't dig so deep in one that you become a masterful guru at the expense of being blind to other options - technology IS a moving target.
Possibly the most difficult of all(?): Learn to say, "No"
I know this is a pro Windows audience but keep in mind that if you specialize in it you are always going to be one step behind by default. An example (perhaps strawman?) is the, "I'm coming from platform X and need to know of a similar IDE for platform Y." Instead of learning a workhorse text editor, what any developer ultimately needs to use once wizards, plugins, and generators stop, they prefer to look for yet another IDE; ignoring yet again the learning curve associated with it before they even start learning about the new platform in question. And then when platform/language/technology Z comes out it is rinse, lather, repeat. Meanwhile the person who knows fundamental concepts combined with smarter choices in tools is able to move on and hit the ground running. The other is posting yet again in another forum asking the same rehashed questions from the last time they didn't learn their lesson. See all the time being wasted here...And over an IDE of all things.
"How do you balance skills development with productivity?" You work smarter and leverage your time better by thinking about what it is your doing - working yourself out of work if you will. Time is your enemy and your friend - learn to manage it better short term, long term, in general. It isn't specific to this field and any successful person will have this as an underlying theme to their success.
I sometimes long for the time when I was so green I didn't know any better. It seems the more I learn the less I know.
Friday, August 18, 2006
As someone who developed a huge abstraction that can't count the features of it on his fingers because they are so many, I think there's not a simple way to really break out of the normal loop provided by your tools.
Every abstraction you try to create on your own has more potential for being a time sinker than a time saver. But on the contrary, when somebody else creates a good abstraction for you, the penalty for adopting it has the potential to being much smaller, as long as the provider and the user don't drink some kind of KoolAid.
POOP is similar to scripting. That is, your role is just to glue the pieces together, but the potential for something disastrous may grow exponentially as you try to create some custom abstractions, just as well as if you copy lots of code everywhere, multiplying the maintenance headache. If the goal is to multiply the maintenance headache, then go ahead.
An easy piece of advice is to simply keep the encapsulations in place. I don't understand why people prefer to copy lots of code everywhere, instead of creating some generic library function, or some generic library, that even in a POOP style can help in keeping things sorted.
I think most developers will always miss abstraction features, as their brains and their deadlines are not trained and not far enough, respectively. It's not bad per se, because abstractions are hard to create, are hard to maintain, and hardly pay off in one project only.
Keep studying, keep doing the same thing. :-) Isn't that the advice?
Friday, August 18, 2006
>How do you justify this when there is an endless queue of work to be done?
Read DeMarco's book "Slack." Then have your boss read it.
If you don't get 10% of your time scheduled for study, learning, training, and slack - then your boss is setting up your team for failure, and you for burnout, or mediocrity.
Monday, August 21, 2006
It's a tough balance to strike. Sometimes I work more, sometimes I study a bit more. I think the most important thing is to make sure you're making steady progress (or have plans to make progress) in both.
I agree with Flow also. You can't expect people to be operating at 100% machine-like efficiency at every second.
Since you will never be 100% done, it is perfectly sensible to spend some time on professional advancement.
If not your employer is setting up for burnout and high turnover.
For the individual, burnout and career stagnation.
Organizations that want to retain people long term, like the armed services and IBM (at least in the old days) devote a lot of time to training. Maybe 10% is too little.
10% training, 10% future projects, seems like a minimum for a productive organization that can handle new requirements.
dot for this one
Monday, August 21, 2006
1. Keep coming here. Someone will offer something that you haven't heard about and you can spend an hour or two checking it out.
2. Take baby steps out of your comfort zone when you can -- i.e., learn complementary technologies/languages. VB/any-bracket-language/SQL will together give you the cornerstones of almost all programming languages. And with those in your arsenal, it's a lot easier to peruse others.
3. Know thy limits. I have learned this one the hard way; I just don't have the time to explore every new shiny object that the world pumps out. Focus your "free time" energy on topics that truly interest you (and hopefully apply to your career).
4. Suck it up and accept that at least half of your "research" time is what others commonly refer to as "free" time. Yes, I do have research time at work, but that only comes when there aren't fires in the kitchen: sometimes days a time, others it's an hour a quarter.
5. Skim books. Yep, it can be expensive, but it's an easy way to identify the topics that you just can't work into your life (at least right now). I've been coding for 10 years, and I've got, jeez, over a hundred tech books in my library. I've skimmed some only to eventually come back to them because they fit a certain situation. It's a *great* way to at least know that the widget is out there and what it can do.
6. Attend the free stuff somewhat regularly (like once a quarter). I think it's easier if you're a Microsoft coder and near a metropolitan area, but there are dozens of free 2-hour seminars going on every month being held by MS and user groups.
That's how I do it, anyway. :)
Wednesday, September 06, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz