6 ms·

How should I be evaluating myself? The only metric that matters is the delta between what you know and what you need to know to build what you have to build. H

by edw519 15y ago

How should I be evaluating myself? The only metric that matters is the delta between what you know and what you need to know to build what you have to build. How do you find out what this is? By building that which must be built. When you get stuck, you will have to find a way to get unstuck: by getting educated, by consulting others, by finding others' solutions, or just by old fashioned figuring it out. How often? Continuously. How should I decide what to work on? Work on what needs to be worked on, not what you need to get better at. Any other approach would be backwards. By definition, the "Competency Matrix" you cite is a bad goal. Every entry has different level of importance for every person and every situation. By trying to aspire to this flawed ideal, you will be wasting time on things that aren't important and missing things that are. (Aside: When I reviewed the Competency Matrix, I had to laugh. Many of the items were so important that you couldn't help getting better at them just by building lots of stuff. And many will never be important at all.) The best way to get good at what you should be getting good at is to build what needs to be built. Then trust the process and yourself to fill in the gaps. Does my ability relative to others matter? No! There will always be many people better than you. There will always be many people worse than you. You will probably be the best at something (or some combination of skills). You will probably never get very good at something (or some combination of skills). And you know what? It doesn't matter! All that matters is whether or not you can successfully build that which must be built. The ability to figure out what that is and how to do that is the most important skill of all. Moral of the story: Go find out what people need. Then build it. The more you become concerned with their needs and the less about your own, the sooner you'll take care of both.

gldalmaso 15y ago
Precisely. The best measure is what you need to learn to scratch your itch. I like to call it just-in-time learning. A good place to look for where to improve is by reading your own code. Read stuff you wrote a week ago. Are you happy with it? What's wrong with it? Too verbose? Not legible enough? Poor perfomance? If you don't know exactly how to improve, try leaving your safety zone. Experiment with different languages or designs, see what they have to offer that your current toolbox is lacking.
epenn 15y ago
All that matters is whether or not you can successfully build that which must be built. The ability to figure out what that is and how to do that is the most important skill of all. I would add to this that it's important to learn how to build what must be built efficiently. If you create what appears to be an elegant piece of software on the surface but resembles a Rube Goldberg machine internally then it's going to be quite difficult to maintain or enhance it later.
- Farris 15y ago
  The next step would then be to expand the functionality of whatever you built by making it do something it was not originally supposed to do. You should then discover the shortcommings of your original solution and from that learn how to work your way around it or that it might be necessary to rebuild it because you did a crap job the first time. Rebuild stuff!
feral 15y ago
Lets say someone is just starting their tennis training. They like the game, but they want to learn how to play well. Would you tell them that all that matters is whether they manage to beat their next opponent, and to focus on that? Or might you say "Dont worry about whether you win or lose for a while, instead focus on improving your fundamental skills"? The first strategy, where you only learn whatever you need to to achieve the next immediate goal, is a bit like greedy optimisation. Its got its merits; but its also got its flaws - for example, you could pick up bad habits that help you win your first few games, but then hinder your later development. Most teaching of advanced topics, which typically happens at university, seem to focus on building a broad foundation of theory, and move on to applications later; the whole idea underpinning this is that we can learn more efficiently than by just having people focus on solving the next problem they have. I would advocate planning ahead, to try and find efficient paths through the space of programmer knowledge. Hence I disagree with edw519's advice - if you are on a mission to improve your general programming, I think you are starting in the right place, by evaluating where you are, and trying to figure out whats most efficient to learn. There is merit to grounding learning in solving real problems; but there's merit to trying to think ahead, and anticipate, too.
- greyfade 15y ago
  I didn't know that by programming, I was playing tennis.
- xarien 15y ago
  I agree somewhat, but would shorten that to: "pay attention to the whys when you learn the hows."
- billpatrianakos 15y ago
  Tennis and programming = bad analogy. When you program you have to know far more than just how to make the code work. You're usually learning at least 3 languages to get one program working, you have to understand the interactions between your program and the server or the OS and the hardware that your software will run on, then you get into maybe learning how certain compilers work, your IDE and other tools, frameworks, object oriented or functional style, etc. On top of that everything is constantly changing on you. In tennis you have a set of unchanging rules. The equipment may advance slightly over the years but they're basically the same. So you really in tennis you learn the rules, strategies, equipment, and you're good. You could program all your life and not even scratch the surface of it all. That's why I think edw's advice is totally perfect. Learning by finding out how to get a task done is the way to go because you could learn all sorts of programming related stuff all day that you never use. In tennis you're far more likely to get an opportunity to use all you've learned. Nice try with the tennis, it's a good argument but it doesn't work out in the end.
runjake 15y ago
Ed, you're an odd cookie. You always give the obvious, common sense answer. But you always give it in a way that provokes thought and reflection, even if we already know the answer. So, thanks. :)
CRASCH 15y ago
This is slightly off topic but may be of value. When I solve a particularly difficult problem, I stop and ask myself a couple of questions that help me grow as a developer. * If I created the problem, How could I have avoided creating this problem? Was it a design error, was I careless or sloppy, did I fail to test or understand something? * How did I solve the problem? What steps did I take to solve it? How can I optimize my problem solving skills to solve problems quicker. Does this apply to a broad range of problems or is likely a unique problem?
FredBrach 15y ago
It remember me a party where a friend was constantly asking me and a couple of school mates what algorithmic is... oh gosh=) So, we were making huge explanations with 'complex' words.. It lasted hours =) Finally, she said: "Oh I think I got you guys, you are finding solutions to solve problems." Happy! :>

by edw519 15y ago

gldalmaso 15y ago

Precisely. The best measure is what you need to learn to scratch your itch. I like to call it just-in-time learning. A good place to look for where to improve is by reading your own code. Read stuff you wrote a week ago. Are you happy with it? What's wrong with it? Too verbose? Not legible enough? Poor perfomance? If you don't know exactly how to improve, try leaving your safety zone. Experiment with different languages or designs, see what they have to offer that your current toolbox is lacking.

epenn 15y ago

All that matters is whether or not you can successfully build that which must be built. The ability to figure out what that is and how to do that is the most important skill of all. I would add to this that it's important to learn how to build what must be built efficiently. If you create what appears to be an elegant piece of software on the surface but resembles a Rube Goldberg machine internally then it's going to be quite difficult to maintain or enhance it later.

Farris 15y ago
The next step would then be to expand the functionality of whatever you built by making it do something it was not originally supposed to do. You should then discover the shortcommings of your original solution and from that learn how to work your way around it or that it might be necessary to rebuild it because you did a crap job the first time. Rebuild stuff!

feral 15y ago

Lets say someone is just starting their tennis training. They like the game, but they want to learn how to play well. Would you tell them that all that matters is whether they manage to beat their next opponent, and to focus on that? Or might you say "Dont worry about whether you win or lose for a while, instead focus on improving your fundamental skills"? The first strategy, where you only learn whatever you need to to achieve the next immediate goal, is a bit like greedy optimisation. Its got its merits; but its also got its flaws - for example, you could pick up bad habits that help you win your first few games, but then hinder your later development. Most teaching of advanced topics, which typically happens at university, seem to focus on building a broad foundation of theory, and move on to applications later; the whole idea underpinning this is that we can learn more efficiently than by just having people focus on solving the next problem they have. I would advocate planning ahead, to try and find efficient paths through the space of programmer knowledge. Hence I disagree with edw519's advice - if you are on a mission to improve your general programming, I think you are starting in the right place, by evaluating where you are, and trying to figure out whats most efficient to learn. There is merit to grounding learning in solving real problems; but there's merit to trying to think ahead, and anticipate, too.

greyfade 15y ago
I didn't know that by programming, I was playing tennis.
xarien 15y ago
I agree somewhat, but would shorten that to: "pay attention to the whys when you learn the hows."
billpatrianakos 15y ago
Tennis and programming = bad analogy. When you program you have to know far more than just how to make the code work. You're usually learning at least 3 languages to get one program working, you have to understand the interactions between your program and the server or the OS and the hardware that your software will run on, then you get into maybe learning how certain compilers work, your IDE and other tools, frameworks, object oriented or functional style, etc. On top of that everything is constantly changing on you. In tennis you have a set of unchanging rules. The equipment may advance slightly over the years but they're basically the same. So you really in tennis you learn the rules, strategies, equipment, and you're good. You could program all your life and not even scratch the surface of it all. That's why I think edw's advice is totally perfect. Learning by finding out how to get a task done is the way to go because you could learn all sorts of programming related stuff all day that you never use. In tennis you're far more likely to get an opportunity to use all you've learned. Nice try with the tennis, it's a good argument but it doesn't work out in the end.

runjake 15y ago

Ed, you're an odd cookie. You always give the obvious, common sense answer. But you always give it in a way that provokes thought and reflection, even if we already know the answer. So, thanks. :)

CRASCH 15y ago

This is slightly off topic but may be of value. When I solve a particularly difficult problem, I stop and ask myself a couple of questions that help me grow as a developer. * If I created the problem, How could I have avoided creating this problem? Was it a design error, was I careless or sloppy, did I fail to test or understand something? * How did I solve the problem? What steps did I take to solve it? How can I optimize my problem solving skills to solve problems quicker. Does this apply to a broad range of problems or is likely a unique problem?

FredBrach 15y ago

It remember me a party where a friend was constantly asking me and a couple of school mates what algorithmic is... oh gosh=) So, we were making huge explanations with 'complex' words.. It lasted hours =) Finally, she said: "Oh I think I got you guys, you are finding solutions to solve problems." Happy! :>