What do you do regularly to evaluate if you are getting better?
https://news.ycombinator.com/item?id=4626695
Personally I don't see much value in telling someone they need high-level CS studies to be a good programmer. How does knowledge of NP-hard problems really help your average developer? I feel that this comic more closely represents the average programmers situation (based on subjective anecdotal evidence only): https://pbs.twimg.com/media/B64WFyuCIAAjq3u.png
Additionally, to remain on the steep learning curve, I think its imperative to expose yourself to well written code and solving different set of problems.
You sound like you are watching your feet when you are running, start looking ahead. Set some goals for the year. Your career is a marathon not a sprint. The items mentioned above are activities that could contribute to you reaching a goal, but they are not goals (except b) and they are not testable.
“Do not confuse motion and progress. A rocking horse keeps moving but does not make any progress.” ― Alfred A. Montapert
My favorite part of this analogy is that the classical Greek marathon tale ends with the death of the runner because he gave it everything he had.
We call those people workaholics.
I want to be good, but not dead. :-D
You can only measure against yourself. Keep a record. Review it from time to time.
A lot of people have vague goals like "I want to learn French" or "I want to be fluent in Japanese." There is no defensible definition of the word "fluent." Instead, you should have specific goals which test ability to complete tasks that are representative of the larger set of tasks you need to be good at to achieve metagoals which are important to you.
This is why I care relatively little about "fluency in Japanese" and quite a bit about "what percentage of commercially significant terms in my apartment lease did I understand without having to ask a Japanese speaker to explain them to me?" That task is roughly representative of many tasks required to achieve my metagoal, which is "being a functioning adult / educated professional in Japanese society."
Now how do I measure progress? Well, I have some notion of groupings of tasks by difficulty level. The "apartment lease" task is in the same grouping and difficulty level as the "employment contract" task was or the "extract the relevant rule for recognizing SaaS revenue from the National Tax Agency's docs" was. Given roughly comparable levels of difficulty, if I start doing better on a task where previously I did poorly, then I'm progressing.
Why don't I just take Japanese tests yearly? Because my metagoal is not becoming the best Japanese test-taker there is. They are good from the perspective of many decisionmakers, since they allow decisionmakers to compare me against other people in a reproducible and cheap-at-the-margin fashion, but that doesn't get anything that I value. I don't care how I compare to Frank or Taro -- being better than Frank will not save me social embarrassment if I have to ask an accountant "Here is my... um, I don't know what the word is, but it's the piece of paper that records the historical prices I purchased by assets at and then their declining present value representing their worth diminishing over time as calculated by the straight line method. There's an accounting word I'm searching for here and I bet it is followed by the word 'schedule.' DEPRECIATION. Yep, that's the one, thanks."
Anyhow: all tasks are an opportunity to gauge my present skill level. I could, theoretically, even keep a journal of them, and I actually did that back in the day. (It's in the other room at the moment. Entries included things like "9/1/2005: Watched a nightly news broadcast about an earthquake. Understood it was about an earthquake and that there was one fatality. Didn't understand remaining 80%.") This gives me both a list of representative things to try leveling up on and some intrinsic motivation because when adding new entries to it I was occasionally pleasantly surprised how far I had come, where that very rarely occurred to me in the moment. (I often feel "Man I'm totally lost at this!" but exposure to the historical record shows that I'm totally lost on tasks which are MUCH HARDER than the tasks I struggled with years ago and that those tasks are now so below the trivial floor that I've forgotten they were once representative examples of things I wanted to strive to be able to do.)
Treating every little thing as an example to both practice and evaluate progress lets me work on focusing things which generally matter to me, gives me a reasonably quick evaluation cycle, and gives me frequent opportunities to achieve mini-victories even in the course of a long, long, looooong learning process.
Evaluating your skill with engineering is, roughly, similar. What relevant things can you do today which you weren't able to do a while ago? That's the progress you've made. Where possible, structure your life to expose you to new challenges which allow you to gauge your increase in skill, as long as marginal skill in that area is actually valuable to you in achieving your metagoals.
I'd love to read more from you about your experience learning Japanese — though it's possible you already wrote an essay about it that I missed.
Evaluating yourself has the additional problem of various biases working against you. So the real question is: Are interview techniques also the best techniques for self-evaluation?
This is, unfortunately, disastrously false. For example, we know -- via copious academic studies -- that work-sample tests are the best available method of predicting performance. Many companies in the software industry do not administer work-sample tests during job interviews. Instead, they have a disinterested person who you won't work with make up a random question on the spot (seriously, this is not only a thing that exists in the world, it is the default hiring method in our industry). The disinterested engineer interviewing you then spends most of their time preening about their own intelligence while ignoring your answer, and returns a decision known to be primarily determined by demeanor, rapport, demographic similarity, and other things which all decisionmakers will profess that they are not assessing for.
Do not pattern your internal decisionmaking off of software interviews. Software interviews suck.
[Edit to add: Incidentally, one of the reasons that one would predict "Well, clearly identifying talented candidates is important, so there is an incentive to get it right, so weak form Efficient Market Hypothesis suggests that companies are not freaking terrible at it." and still be disastrously wrong about the world we live in is that interviews have a principal/agent problem. The principal -- the firm -- cares a lot about extracting meaningful signal in interviews. The agent -- the engineer who is responsible for interviewing you -- is in no way rewarded for interviewing well. In many cases, their presence in the interview is already a strike against them because it takes time from doing the engineering work that they are actually scored on. They have not even the attenuated incentive to select good coworkers, because 90% of interviews result in No-Hire and of the remaining 10% the 95%++ case is that the new hire ends up working in some other part of the organization that the interviewing engineer will never need to meaningfully interact with. Faced with these very attenuated incentives for being a good interviewer, the engineer may instead to pay attention to more direct incentives like "get an ego boost by demonstrating my intellectual superiority over a captive, terrified, unable-to-resist audience."]
Yes - :8( I'm not getting better.
No - :8) Lucky me, I'm getting better.
It's simplistic, but it's resonated with me for 30+ years.
You could try writing down whatever you learn each time you learn something new to so you can look back and realize you are getting better, assuming you are. If you aren't then at least you know and can reevaluate.
What makes a good compiler developer for Microsoft is going to be very different from what makes a good developer at a start up. If you plan on working at start ups, particular early stage start ups, it would be very beneficial to see where you are lacking any experience to increase your breadth. For instance are you familiar with source control, unit testing, scripting, database optimization, communication skills, trouble shooting, etc... Find any skill where you are behind some of your pears and improve it. Obviously a combination of reading and practice will help you get there.(With the proportions of each depending on the skill)
If for instance you are a developer for the Microsoft compiler it might be beneficial to go really deep. Find as many papers as possible on language design, compiler design, etc... Maybe work on a couple of different open source compilers to get introduced to more ideas, or implement some new language ideas from papers into an open source compiler, while trying to minimize any types of breaking changes. But these skills and how you improve upon them are probably very different from what makes a good start up developer.
*Warning I do not actually know what skills are needed to be a Microsoft compiler writer, or a good start up developer, these were just examples to illustrate a point. My experience has been primarily enterprise, and I probably should have used that as an example but now its too late because the compiler is finishing up.
How to choose it? It depends on the reason why you would like to improve: to be more attractive on the job market? To spend less time coping with specific problems? To earn more money? To gain recognition for your work? To have more personal satisfaction from what you do and how you do it? etc. Knowing the "ultimate" goal can help decide what exactly you want to focus on, establish a baseline and measure the progress.
Interviews are a whole different world so I don't think that they test how much you have actually improve.
Creating your own products is a great way to improve your code. Learn about the system your want to design, create the database, write your services, do the UI and iterate. After a few failed products you'll understand that what ever your wrote until know it was crap and your code will be cleaner and better.
The best would be to contribute to open source projects. That way you have to study other peoples code. Understand it. Improve it. And then send your code for it to be reviewed and merged for the whole world. Off course it will always depend on how good the original author of the project is.
"I want to make a popular app" - ok, pick a target number of users. Maybe 10,000? Or 100,000? Then go make something that'll be relevant and popular[1].
"I want to make more money" - ok, figure out how much more you want to earn, and then figure out how to go get that job.
Regardless, you need to be thinking about the long term.
[1] I am well aware it's not as simple as this :)
Also: How good is your documentation? The more experience you gain the more you will be able to plan ahead and build the a scaffold first before you start fiddling with details. This often leads to well documented code where the documentation always matches the code. A lot of tinkering often means that the documentation and your code won't match.
How well do you know your tools/frameworks/language? Can you start coding or do you find yourself trying out something in a REPL or a small test project before implementing it? (Note: This may vary since even quite senior developers have to learn new tools)
How well can you explain your code / your program / your project? Once again getting a good grasp at complexity is a matter of training.
Compare your code to open source projects and other code you can find. You'll see that there are always some good practices one still can learn. On the other hand becoming more experienced will make you see code and decide that there is room for improvement or you would have structured it better.
Watching videos of presentations or listening to them during the commute (if possible, given the topic) will work. Optimistically a video from 2010 that was pure confusion at the time might be crystal clear when heard today.
I don't currently work at a strong dev culture place with many devs, but at a previous employer we'd brown-bag lunch and watch presentations together, and sometimes the company would provide food or we'd all chip in for pizza. Its a fun way to spend a rainy lunch hour. You need to set up a rotation of who picks the topic or everyone will go crazy. Do not let management pick the videos or you'll all be stuck watching OSHA videos, until everyone stops attending anyway. Corporate videos were the worst, con videos were generally pretty interesting.
I think one way that might work is to have many programmers evaluate each other holistically. A competent judge could take into account experience, intelligence, personability, hardworkingness, and myriad other intangibles. You could have a bunch of devs rank everybody they've ever worked with; then combine all the rankings, and the ones near the top would be pretty close to the best.
This system wouldn't be perfect because it would be affected by politics, but maybe those effects could be mitigated by keeping voting anonymous. And the people at bottom would hate it and never accept it as valid. But even with its flaws, I think this would be a pretty accurate measure.
I would say the next best measure is option b mentioned by OP -- shipping lots of real products. There you have concrete metrics like dollars earned and development time required. But, of course, it takes many years to get a sufficient sample size to demonstrate improvement.
In any case you must be more specific than "being good as a software developer".
PS: I even know about some guys who are nearly hated by their coworkers for their love of detail, but it's doing good things for the company as a whole. So these guys are good and bad for the same people at the same time. How to evaluate that?
Debugging
Architecture
Release Management
Git / Version Control / Branching Strategy
Scoping (chunking, costing)
Problem solving (fuzzy reqs)
Communication
Patience
Mental Discipline
Code Review
Every other week, we each self-assess in these areas, and pick three that we want to improve upon for the month/quarter/whatever. Then we keep track of our self assessments over time.
So far the self assessments have been pretty accurate.
1) technologies: are you growing in the number of frameworks and tools you use? Do you use them better and well? Do they span the tech stack or are they all concentrated in areas (frontend, db engines ... etc)? The more the better, but also quality of use is important. When you look at a code base and know exactly how to debug an issue because you know exactly how the views/models/db are synced up in that framework you will produce faster ... hence you are better
2)Do you have a process to coding? Good but why did you choose that process? If you dont have one then try to make one. You have some experience programming so you should be able to look at history of projects created and understand how you could have implemented them better. Make a process for frontend ui, for testing, for db migrations, for commiting code ... for every part of your process and iterate. Have an opinion on why you do the things you do. Use logic. You might not have the most efficient process but any process will make you more efficient and most importantly youll have something to compare with others so that you can swap their better techniques in later or mix them with your own.
3)I think interviewing can be the best way to test yourself. In interviewing you a)define areas of programming you think are important b)you understand how to display these areas in the form of code c)you are able to explain and help a developer walk through the key areas of a problem. If your interviews are getting more complicated then you are probably in charge of more complex code so you are becoming a better programmer.
After that, I move on to working on my projects. Some stuff comes easier than it used to for me. Some stuff kicks my butt. Ultimately, it reinforces two things...
1. I've gotten better in some respects.
2. I'm still a lot worse than I previously realized.
A) Yes: You are already perfect in every way.
B) No: Look at something you wrote a year previously, would you implement the solution the same way today?
B1) Yes: Fail.
B2) No: You Win!
I believe Topcoder has design competitions too.
h)... i)PROFIT
;-) now serious!
Refactoring!
Sometimes I learn something new, then I revisit any project I started and refactor it.
If you want to get some numbers to compare, you might look on lines of code removed, or timing the operation took. If it gets better, you can smile and say, I'm smarter than myself in 2014
