TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

76 pointsby tathagatadgabout 10 years ago
(a) contributing to open source projects. long term disciplined approach, takes time to get evaluation (b) ship a real product. too many environmental parameters, takes time to get evaluated (c) participate in coding competitions. These tend to test your algorithm chops, and less of system design. But accurate results. (d) be generous about recruiter requests. show up for interviews without doing much interview prep (like practicing problems cracking coding interviews). but quick and fast evaluation. This gets very hard when you don&#x27;t work remotely. (e) exact opposite to (d). be picky about interviews, prepare a lot for an interview. (f) attend conferences, hackathons. time consuming and may be costly and not sure how effective it is. (g) read some classic cs books cover to cover. no accurate measure<p>What do you do regularly to evaluate if you are getting better?

33 comments

brixonabout 10 years ago
Reflect on the past year or so.<p>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.<p>“Do not confuse motion and progress. A rocking horse keeps moving but does not make any progress.” ― Alfred A. Montapert
评论 #9341095 未加载
Splendorabout 10 years ago
I use Sijin Joseph&#x27;s Programmer Competency Matrix[0] as a guide.<p>[0]: <a href="http:&#x2F;&#x2F;sijinjoseph.com&#x2F;programmer-competency-matrix&#x2F;" rel="nofollow">http:&#x2F;&#x2F;sijinjoseph.com&#x2F;programmer-competency-matrix&#x2F;</a>
评论 #9341959 未加载
评论 #9342936 未加载
JamesBarneyabout 10 years ago
I think one of the problems with &quot;How to improve as a software developer?&quot; 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.<p>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)<p>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.<p>*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.
ArekDymalskiabout 10 years ago
Taking into account that being a developer requires a really broad range of competencies (from &quot;hard&quot; knowledge about languages, frameworks, databases, systems and so long, through a variety of skills like analyzing, solving problems etc. to &quot;soft&quot; 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.<p>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 &quot;ultimate&quot; goal can help decide what exactly you want to focus on, establish a baseline and measure the progress.
agentultraabout 10 years ago
I open up some old repositories. If I cringe and spot mistakes I had made then I know I&#x27;ve improved. Sometimes I spot areas where I&#x27;ve regressed in my knowledge and need to practice.<p>You can only measure against yourself. Keep a record. Review it from time to time.
评论 #9342306 未加载
stevooabout 10 years ago
Most of these are hard to measure. It will come down to your own variables.<p>Interviews are a whole different world so I don&#x27;t think that they test how much you have actually improve.<p>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&#x27;ll understand that what ever your wrote until know it was crap and your code will be cleaner and better.<p>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.
aaronbrethorstabout 10 years ago
<i>Why</i> do you want to test that you&#x27;re improving? Start by answering that question. Once you&#x27;ve done that, focus on understanding how to improve whatever metrics are associated with your reason. For example:<p>&quot;I want to make a popular app&quot; - ok, pick a target number of users. Maybe 10,000? Or 100,000? Then go make something that&#x27;ll be relevant and popular[1].<p>&quot;I want to make more money&quot; - ok, figure out how much more you want to earn, and then figure out how to go get that job.<p>Regardless, you need to be thinking about the long term.<p>[1] I am well aware it&#x27;s not as simple as this :)
probinsoabout 10 years ago
read project code from a year ago. also have a person review your code in a language you are new to.
评论 #9340643 未加载
评论 #9340979 未加载
phelmigabout 10 years 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.<p>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&#x27;t match.<p>How well do you know your tools&#x2F;frameworks&#x2F;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)<p>How well can you explain your code &#x2F; your program &#x2F; your project? Once again getting a good grasp at complexity is a matter of training.<p>Compare your code to open source projects and other code you can find. You&#x27;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.
VLMabout 10 years ago
&quot;(f) attend conferences, hackathons. time consuming and may be costly and not sure how effective it is.&quot;<p>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.<p>I don&#x27;t currently work at a strong dev culture place with many devs, but at a previous employer we&#x27;d brown-bag lunch and watch presentations together, and sometimes the company would provide food or we&#x27;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&#x27;ll all be stuck watching OSHA videos, until everyone stops attending anyway. Corporate videos were the worst, con videos were generally pretty interesting.
patio11about 10 years 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?<p>A lot of people have vague goals like &quot;I want to learn French&quot; or &quot;I want to be fluent in Japanese.&quot; There is no defensible definition of the word &quot;fluent.&quot; 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.<p>This is why I care relatively little about &quot;fluency in Japanese&quot; and quite a bit about &quot;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?&quot; That task is roughly representative of many tasks required to achieve my metagoal, which is &quot;being a functioning adult &#x2F; educated professional in Japanese society.&quot;<p>Now how do I measure progress? Well, I have some notion of groupings of tasks by difficulty level. The &quot;apartment lease&quot; task is in the same grouping and difficulty level as the &quot;employment contract&quot; task was or the &quot;extract the relevant rule for recognizing SaaS revenue from the National Tax Agency&#x27;s docs&quot; was. Given roughly comparable levels of difficulty, if I start doing better on a task where previously I did poorly, then I&#x27;m progressing.<p>Why don&#x27;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&#x27;t get anything that I value. I don&#x27;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 &quot;Here is my... um, I don&#x27;t know what the word is, but it&#x27;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&#x27;s an accounting word I&#x27;m searching for here and I bet it is followed by the word &#x27;schedule.&#x27; DEPRECIATION. Yep, that&#x27;s the one, thanks.&quot;<p>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&#x27;s in the other room at the moment. Entries included things like &quot;9&#x2F;1&#x2F;2005: Watched a nightly news broadcast about an earthquake. Understood it was about an earthquake and that there was one fatality. Didn&#x27;t understand remaining 80%.&quot;) 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 &quot;Man I&#x27;m totally lost at this!&quot; but exposure to the historical record shows that I&#x27;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&#x27;ve forgotten they were once representative examples of things I wanted to <i>strive to be able to do</i>.)<p>Treating every little thing as an example to both practice and evaluate progress lets me work on focusing things which generally <i>matter</i> 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.<p>Evaluating your skill with engineering is, roughly, similar. What relevant things can you do today which you weren&#x27;t able to do a while ago? That&#x27;s the progress you&#x27;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.
评论 #9342937 未加载
elrosabout 10 years ago
I read old code I wrote. &quot;What were these people thinking?&quot;
cdbajorinabout 10 years ago
Read through other people&#x27;s code and criticize their decision-making. Answer questions on SO related to whatever you&#x27;re currently doing. If you can&#x27;t explain it, you don&#x27;t really know it.
JesseAldridgeabout 10 years ago
I don&#x27;t think there is a good, established way. It&#x27;s funny how many devs answer this question by waving their hands and saying, &quot;everybody&#x27;s a winner!&quot;<p>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&#x27;ve ever worked with; then combine all the rankings, and the ones near the top would be pretty close to the best.<p>This system wouldn&#x27;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.<p>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.
qzncabout 10 years 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.<p>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?
评论 #9341530 未加载
erikbabout 10 years ago
I think your choice shows a very simple misunderstanding. Programming is not one thing. It&#x27;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&#x2F;departments&#x2F;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.<p>In any case you must be more specific than &quot;being good as a software developer&quot;.<p>PS: I even know about some guys who are nearly hated by their coworkers for their love of detail, but it&#x27;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?
endlessvoid94about 10 years ago
I use a skills matrix with my team that contains the following:<p>Debugging<p>Architecture<p>Release Management<p>Git &#x2F; Version Control &#x2F; Branching Strategy<p>Scoping (chunking, costing)<p>Problem solving (fuzzy reqs)<p>Communication<p>Patience<p>Mental Discipline<p>Code Review<p>Every other week, we each self-assess in these areas, and pick three that we want to improve upon for the month&#x2F;quarter&#x2F;whatever. Then we keep track of our self assessments over time.<p>So far the self assessments have been pretty accurate.
akilismabout 10 years ago
Am I making the same mistakes?<p>Yes - :8( I&#x27;m not getting better.<p>No - :8) Lucky me, I&#x27;m getting better.
评论 #9341114 未加载
thisguyproabout 10 years 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.<p>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&#x2F;models&#x2F;db are synced up in that framework you will produce faster ... hence you are better<p>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.<p>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.
rifungabout 10 years ago
One thing I like to do which isn&#x27;t at all specific to software is writing down accomplishments. This way I can look back and see if I&#x27;ve been progressing or staying still.<p>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&#x27;t then at least you know and can reevaluate.
评论 #9341923 未加载
yodsanklaiabout 10 years ago
Interesting question. I don&#x27;t think there&#x27;s a perfect metric to rate software developers. One issue is that it&#x27;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.
pcoteabout 10 years 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.<p>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...<p>1. I&#x27;ve gotten better in some respects.<p>2. I&#x27;m still a lot worse than I previously realized.
iherediaabout 10 years ago
Review your older projects. Sometimes when I look at old code that I wrote I can&#x27;t help but think a lot about how now I would design &#x2F; implement the whole thing with a different approach. Usually that makes me realize how much I&#x27;ve learn in the last time
moron4hireabout 10 years ago
You sound like you&#x27;re rushing. This is a journey of several decades, not a few weeks.
khorwitzabout 10 years ago
How fast do you ship products and&#x2F;or deliverables to the world and to your bosses?
评论 #9340592 未加载
rogerbinnsabout 10 years ago
Update your resume&#x2F;CV periodically (eg every month, quarter or year). If you don&#x27;t have something to write about, then you are likely not improving. If you are improving then you&#x27;ll have a nice record.
tracker1about 10 years ago
Are you Jon Skeet?<p>A) Yes: You are already perfect in every way.<p>B) No: Look at something you wrote a year previously, would you implement the solution the same way today?<p>B1) Yes: Fail.<p>B2) No: You Win!
yodsanklaiabout 10 years ago
&gt; (c) participate in coding competitions. These tend to test your algorithm chops,<p>I believe Topcoder has design competitions too.
jkingsberyabout 10 years ago
Assuming you are working with a team, you can always just ask others for feedback on how you&#x27;re doing.
jmolinasoabout 10 years ago
you forgot 2 more points<p>h)... i)PROFIT<p>;-) now serious!<p>Refactoring!<p>Sometimes I learn something new, then I revisit any project I started and refactor it.<p>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&#x27;m smarter than myself in 2014
interdriftabout 10 years ago
I do only one thing : I solve problems and compare my results every week or so.
sjg007about 10 years ago
Think very hard. Write code, lots of it. Get code reviews. Repeat.
kluckabout 10 years ago
You are programming less.