Hot answers tagged skills
Deciding TO be a 'Jack-of-all-Trades' Fairly early in my career, I was an expert with a particular database and programming language. Unfortunately, that particular database lost the 'database wars', and I discovered that my career options were ... limited. After that I consciously decided that I would never let myself become boxed in like that again. So ...
I always thought of my self as a pretty hot-shot programmer. Then a new guy, call him Aaron, was hired into our team. Aaron was obviously much better than me in most areas. He was younger than me, too. He made me realize I hadn't really improved much in the past years. I was an ad-hoc hacker, and a mediocre one at that. This alerted me to consciously ...
Two things: Read code written by different people. Write documentation for code written by other people. Writing code is extremely easy; every other person I know can do that. But reading someone else's code and figuring out what it does was a whole new world to me.
The biggest clue for me is: When you have to go back and add/modify a feature, is it difficult? Do you constantly break existing functionality when making changes? If the answer to the above is "yes" then you probably have a poor overall design. It is (for me at least) a bit difficult to judge a design until it is required to respond to change (within ...
When to ask for help, and when NOT to ask for help.
First, as a senior developer, I expect the juniors I lead on projects to bring their concerns to me in a straight forward and direct manner. If they disagree, that's perfectly alright with me. In some cases, I will take action on their concerns. In most cases, their concerns are tossed aside put aside with a short explanation of the reasoning, not out of ...
How to read other people's code.
Took a part-time job tutoring CS students at my university. It really forces you to understand something at a completely different level when you have to explain it to someone else.
There is a trick, one that a junior successfully pulled on me (the extremely bad tempered know-it-all senior developer): Do whatever you are asked to do, and exactly how you are asked to do it - be fantastically professional or go home, If you have (any) concerns, write them down - never assume you'll remember (true developers log everything), If ...
Familiarity with version control systems. It doesn't have to be every one, but the basic concepts that can be applied to all of them should be known.
This is certainly a pretty standard measure where I work. Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are ...
Looking back at old things I wrote and realizing just how bad they were.
Maybe it's too subtle, but I think of it as "knowing which problem to solve." A lot of programmers (and normal people) waste tremendous effort solving things that simply aren't very important; or they create a solution, with a great deal of extra work, that isn't quite what is needed.
How to relax. It's the secret to productivity. Eventually, willpower and caffeine are not enough. This constant contraction we do is very damaging. This is a big deal.
Read books, not just websites for self-improvement, not just for the latest project about improving your trade, not just about the latest technology read code, not just you are working on. Just develop the appetite for reading.
Don't worry about meeting some ridiculous concept of "skill" so commonly heard in such statements like: All programming languages are basically the same. Once you pick up one language well you can pick up any other language quickly and easily. Languages are just tools, there's some overarching brain-magic that actually makes the software. These ...
Programming. Seriously, there are books, there are coding katas, there are sites like this, but I believe that the best way to improve as a developer is to work on real project, with real fickle customers with real, ever-changing requirements with real engineering problems. There's no substitute for experience.
You know you are writing good code when: Things are clever, but not too clever Algorithms are optimal, both in speed as well as in readability Classes, variables and functions are well named and make sense without having to think too much You come back to it after a weekend off, and you can jump straight in Things that will be reused are reusable Unit ...
Basic data type & algorithm theory. Things like Big O notation, arrays, queues, etc.
I think the most important thing you can do is make a conscious effort to improve. There's no single silver bullet, you have to keep looking for new sources of information, new experiences, and more practice. And the second most important thing, think about what you're doing, why you're doing it, and how you can do it better. Same thing with previous ...
Only top voted, non community-wiki answers of a minimum length are eligible