13 ms·

Ask HN: How do I test that I'm improving as a software developer?

• deleted 12y ago
  [deleted]
• JesseAldridge 12y ago
  I don't think there is a good, established way. It's funny how many devs answer this question by waving their hands and saying, "everybody's a winner!" 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.
• thisguypro 12y ago
  this is specific to the developer part not the management part which takes a number of other skills as any one of us know that work for pay. 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.
• pcote 12y ago
  I do practice programming exercises which get scheduled through Anki flash cards. I relearn things as I go. Then I look at my stats for a sec. 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.
• tracker1 12y ago
  Are you Jon Skeet? 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!
• sjg007 12y ago
  Think very hard. Write code, lots of it. Get code reviews. Repeat.
• kluck 12y ago
  You are programming less.
• iheredia 12y ago
  Review your older projects. Sometimes when I look at old code that I wrote I can't help but think a lot about how now I would design / implement the whole thing with a different approach. Usually that makes me realize how much I've learn in the last time
• elros 12y ago
  I read old code I wrote. "What were these people thinking?"
• khorwitz 12y ago
  How fast do you ship products and/or deliverables to the world and to your bosses?
  • Cephlin 12y ago
    Do you have an ideal that shipping/delivery should conform to?
• probinso 12y ago
  read project code from a year ago. also have a person review your code in a language you are new to.
  • unfunco 12y ago
    I would suggest this also. Every so often it's humbling to look back on your older code and think about how you might write it differently. If you cringe with frequency, you're likely improving.
    • atwebb 12y ago
      Agreed, if you don't cringe either you were already pretty good or you still don't know the same things you missed before.
      • nostrademons 12y ago
        Or you've changed focus. I look at my old code from 10 years ago and on a line-by-line aesthetic basis, it's pretty good. It's probably better than the code I wrote yesterday, given that I haven't yet setup my IDE to reformat it into a consistent style... But that's exactly what's changed in the last 10 years. Now I consider my code in the context of the world around it, and don't waste time doing things that I can get machines (or other people) to do for me. So while my actual code has gotten worse, I'm much more inclined to use third-party libraries and frameworks when appropriate to solve problems. The problems I solve are more important to me. I pay more attention to how the code fits into the rest of the world around me than how it looks inside.
    • deleted 12y ago
      [deleted]
  • myth_buster 12y ago
    Going through your previous implementation gives one sure sign of whether you are improving. When on a steep learning curve, its very easy to spot bad implementation. It's akin to getting your code reviewed by someone with additional year of experience. Although, some of the mistakes you spot may be attributed to perhaps your enhanced domain knowledge but you will be able to distinguish between the two. 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.
• stevoo 12y ago
  Most of these are hard to measure. It will come down to your own variables. 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.
• brixon 12y ago
  Reflect on the past year or so. 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
  • mathgeek 12y ago
    > Your career is a marathon not a sprint. 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.
    • nocman 12y ago
      I, for one, do not want to die because I worked so hard. We call those people workaholics. I want to be good, but not dead. :-D
      • Vaskivo 12y ago
        You don't want to die because you ran too much. What you want is the feeling that, when you die, you ran as far and as fast as you could during your whole life.
• phelmig 12y ago
  How many problems do you miss until you start debugging? Getting complex models and systems right in your head is a matter of training. 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.
• cdbajorin 12y ago
  Read through other people's code and criticize their decision-making. Answer questions on SO related to whatever you're currently doing. If you can't explain it, you don't really know it.
• yodsanklai 12y ago
  > (c) participate in coding competitions. These tend to test your algorithm chops, I believe Topcoder has design competitions too.
• agentultra 12y ago
  I open up some old repositories. If I cringe and spot mistakes I had made then I know I've improved. Sometimes I spot areas where I've regressed in my knowledge and need to practice. You can only measure against yourself. Keep a record. Review it from time to time.
  • balabaster 12y ago
    I do the same with old blog posts... I frequently spot areas where I've regressed and need to practice. The longer I spend doing "real" work between working on prototypes or katas, the more I feel like that's the case.
• yodsanklai 12y ago
  Interesting question. I don't think there's a perfect metric to rate software developers. One issue is that it's difficult to separate general software development skills from the area of expertise. For instance developing web apps, video games, distributed systems, compilers, financial software and so on... all require different types of expertise.
• interdrift 12y ago
  I do only one thing : I solve problems and compare my results every week or so.
• ArekDymalski 12y ago
  Taking into account that being a developer requires a really broad range of competencies (from "hard" knowledge about languages, frameworks, databases, systems and so long, through a variety of skills like analyzing, solving problems etc. to "soft" aspects communicating and cooperating with others, not to mention the business domain requirements which often are crucial) I think you should first focus on finding one narrow area you would like to improve and then seek for a right metric for it. 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.
• nagaiah 12y ago
  You'll be writing less LOC;
• akilism 12y ago
  Am I making the same mistakes? Yes - :8( I'm not getting better. No - :8) Lucky me, I'm getting better.
  • pliftkl 12y ago
    I remember fondly the advice of my first computer science instructor in the mid-80's: Becoming a great programmer is easy! Get a notebook. When you make a mistake, write it down. Don't make that mistake again. It's simplistic, but it's resonated with me for 30+ years.
• moron4hire 12y ago
  You sound like you're rushing. This is a journey of several decades, not a few weeks.
• VLM 12y ago
  "(f) attend conferences, hackathons. time consuming and may be costly and not sure how effective it is." 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.
• Splendor 12y ago
  I use Sijin Joseph's Programmer Competency Matrix[0] as a guide. [0]: http://sijinjoseph.com/programmer-competency-matrix/ http://sijinjoseph.com/programmer-competency-matrix/
  • artmageddon 12y ago
    Funny you should reference this as it's been posted numerous times here on HN, and there's even a debate going on as we speak[0]... [0] https://news.ycombinator.com/item?id=9341146 https://news.ycombinator.com/item?id=9341146
  • noddingham 12y ago
    That is a highly debated matrix as evidenced here: https://news.ycombinator.com/item?id=4626695 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 https://pbs.twimg.com/media/B64WFyuCIAAjq3u.png
    • Splendor 12y ago
      I don't think the point is that you can't be a good programmer unless you understand NP-hard problems (at least I hope so, otherwise I'm in trouble). I think the point is that you can use this matrix as a guide towards improving your knowledge and skills.
      • xxxyy 12y ago
        Exactly. You do not need to understand what does NP-hardness mean to be an excellent developer. Understanding complexity, computability and modern logics is pretty satisfying, I'm personally in love the Godel's incompleteness theorem. But it is just one of many variables. There's plenty of things to improve on.
      • noddingham 12y ago
• qznc 12y ago
  During hiring interviews people want to quickly evaluate the software developer skills and there are obvious incentives to get it right. Thus, the things people are doing during interviews are the best tests we currently know. 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?
  • patio11 12y ago
    Thus, the things people are doing during interviews are the best tests we currently know. 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."]
• JamesBarney 12y ago
  I think one of the problems with "How to improve as a software developer?" is that it represents many different skills. So the first thing to become a better developer, before you read any books, or write any code is to figure out what it means to be a better developer. Specifically where you want your career to take you and how can you make progress on that path. 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.
• rifung 12y ago
  One thing I like to do which isn't at all specific to software is writing down accomplishments. This way I can look back and see if I've been progressing or staying still. 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.
  • fecak 12y ago
    I recommend to candidates I work with to update their resume every 6 months - 18 months (depending on your employer's project timelines). If you find yourself consistently struggling to add things to your resume, whether those are new skills or accomplishments, it's either time to look for a new job or time to start considering projects to maintain marketability.
• jkingsbery 12y ago
  Assuming you are working with a team, you can always just ask others for feedback on how you're doing.
• patio11 12y ago
  This is the core challenge with measuring skills acquisition. To avoid talking my book about measuring developer skill, mind if I instead talk about my first love, which is learning foreign languages? 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.
• rogerbinns 12y ago
  Update your resume/CV periodically (eg every month, quarter or year). If you don't have something to write about, then you are likely not improving. If you are improving then you'll have a nice record.
• endlessvoid94 12y ago
  I use a skills matrix with my team that contains the following: 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.
• jmolinaso 12y ago
  you forgot 2 more points 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
• aaronbrethorst 12y ago
  Why do you want to test that you're improving? Start by answering that question. Once you've done that, focus on understanding how to improve whatever metrics are associated with your reason. For example: "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 :)
• erikb 12y ago
  I think your choice shows a very simple misunderstanding. Programming is not one thing. It's many different things. E.g. someone good at open source might not be even mediocre in a business environment. People are different, goals are different, etc. Even two different FOSS projects or companies/departments/teams might evaluate the same person very differently. Also lets not forget that the most important goal for you might be to program for your own benefit and evaluating just that by yourself. 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?