Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What's the one thing that let you grow the most as a developer?
374 points by main_c on March 3, 2017 | hide | past | favorite | 243 comments
For the last two and a half years I've been developing computer vision algorithms for a proprietary embedded platform in C. Without a proper CS degree (my bachelors and masters were in mechanical engineering), or experience (Stuck writing a very limited subset of C i.e. no malloc(), free(), libraries etc etc), I don't have the confidence to call myself a developer. So I was looking for avenues to maybe improve my skills and knowledge. So in short I'd like to ask, what one thing let you grow/learn the most as a developer?



What improved my coding a lot was simply taking responsibility of projects from start to deployment and beyond. Seeing the future damage of all your shortcuts or entangling yourself in pretty patterns for no good at all really is sobering.

You need to go through at least three Design-Ship-Support cycles of the same product to really appreciate what good coding practices are.

If you're like one-of-many in a project and never really have responsibility for anything I would strongly recommend some external work where you are in total command of everything. I was stuck in a position without that for too long.

------------

By the way: you say you just know C. But how many developers out there feel bad about their skills because they don't have C skills? C is the beginning of everything, everything is built on top of it.


There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call.

I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message.

That's the stuff that comes out in the Support cycle that I think people really only internalize if they learn the hard way.


> There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call.

Alternatively there's nothing like having a junior colleague investigating a defect in code you once wrote ask you what it does and then have to publicly declare that that it was crappy garbage that you can no longer decipher.


Years ago, I was the junior in this situation. Being very careful about how to criticize code publicly/not criticize is a skill in its own right!


Nowadays I always write future proofing code. Like, if I need to make a bad decision/tech debt, I will leave ample documentation explaining why and providing alternatives in a hypothetical better future.

My future self is always happy that this is the new standard. High quality, documented tech debt.


I, too, started leaving comments for myself and other future maintainers to explain why a bad decision or awkward solution was chosen at the time, and offering the list of things I tried along with potential future improvements. Explaining the constraints under which the bad decision was made is important so that my future self can evaluate whether those constraints are still valid.


Where do you write this documentation? Directly in the source code? Or in something like github's wiki? Or something different? If not in the source code, then how do you make the docs discoverable for people reading the source?


As comments, usually. As near to the tech debt as possible.


> I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message.

This is one of the reasons why my current shop has added a new rule. When dev gives my ops team a new release, one of the devs comes to our office and stays here during the initial deployment and test. It's a good feeling to see a dev equally confused about weird crap the application does because it doesn't log and it doesn't work and it's just weird. And for bugs in on-premise systems outside our network, the support devs have even more fun.

Overall, this is a pretty funny development. Both teams grew a silly amount relatively speaking, and due to stress and other issues we had a couple of tensions between teams. But by now both teams are learning.

Ops is annoyed because of some weird config, and dev hates this weird config because it's a huge pain in the code. Oh, teams talked, config was ripped out and simplified.

Dev is desperate about a hard bug regarding request headers, because this might need a hotfix and logging and changes. The admin just shrugged and changed the apache access log with said header, and the problem was resolved 15 minutes later.

I think this is one of the bigger lessons for me. Never assume something to be hard or easy for another team. My huge issue might be a 2 line change while removing a huge pain. Your issue might be something my config management already does.


I've had similar experiences, where I learned about something ops was doing -- such as a really complex script to configure something -- that was easily solved by a simple code change. I always pushed for feedback from ops, saying we'd make whatever changes they needed, but they never asked for much.

What was happening is they just accepted the software the way it is, and because they were capable of writing this complex script, they didn't see the need to ask for help or changes.

I've spent some time recently learning more about the specifics of their deployment and have some changes to make as a result (though since deployment is working, it'll be a slow change since it's more like technical debt and not an immediate problem).

However, I think I'm actually going to suggest we do what you're doing, and actually make a developer go sit with ops whenever they deploy a new release. That's a great idea, thanks.


Look at it from my perspective. I deploy elasticsearch, hazelcast, mysql, apache, haproxy, maxscale, diamond, and a lot of other stuff. All of these applications except diamond are out of my reach to really change. Thus, it becomes natural to accept the software as it is and build workarounds, because you cannot change these applications.

And then there's that one in-house application. It's easy to just lump it into the pile of crap we need to deploy and maintain and handle it in the same way we handle the other services.

And at least at this shop, this was reinforced further for some time. We in ops had two choices: Either, we block a release for hard reasons, no matter how close we'd have to look for them, then we'd get some bandaid quickly. Or we could attempt to explain a highly technical issue or a really weird configuration glitch to some entirely non-technical product management, who put it on the latter half of the "never happens" backlog inside the round ticket storage, which is groomed daily by the room services.

At this point, just scripting around bullshit costs me like 2 hours to do, while all that other nonsense easily costs days and days.

But yeah, all of this is being mediated because devs now see the amount of nonsense we have to do, and they can relate this nonsense with their own testing problems, their own dev setup problems and overall, both teams start to support each other against sales and PM.


This is what did it for me as well.

Even when it was technically outside the requirements of my job, I started stepping up and actually fixing my own shit. And not just bugs or issues, but really feeling the pain of having to deploy it, talk on the phone with the customer and feel the lack of help/debugging stuff built-in to the product, train new users on how to use it, feel the panic as you realize that you cocked up the last deploy and it's going to be offline for like an hour while you scramble to roll back the changes which you thought you figured out months ago but everything changed since then and you are sitting there with nothing.

Slowly but surely I started adding things to my "never do again" and my "needs to be done before launch" lists.


I have a position like this. It sucks.

If you have to take total control of at least project, you'll likely be doing it for all projects.

If the previous project was created by multiple people, but you are now the sole maintainer, it will take more time to work on than the other projects. These are the ones for which you should know like the back of your hand when juggling 10 other low-impact, one-man-army projects.

Lack of QA and Ops means you are limited by your own working set of skills, which is most likely going to be shallow in those areas. It's also very hard to learn dealing with customers on the job in this role -- it's best to have learned it somewhere else. You can write unit and automated tests, but that increases your development time 3 fold (not to mention you already need good unit testing and automated testing skills).

You will feel like you are constantly drowning. The highs are not really that high and the lows are very low. There is no opportunity to master anything other than making the customer happy for a month or so, which is really only so you can meet other customer needs.

You may not have an additional person just to bounce technical ideas off of. This is so much bigger than you can realize if you've gotten used to this kind of one-man-army position, chiefly because you often have little time to actually think about what would make the products better.

None of this feels like growing, only surviving, especially if the next position is going to be a place that has experts in all of the extra areas.


In my situation, it was a greenfield new-project which kind of started off as a "moonshot" and became a real thing, so mistakes and extra development time were much more tolerated (not to mention my employer is pretty awesome!).

It's not ideal, and I'm actually happy to be moving out of that (with what used to be my "one man army" project actually getting a team and managing it).

But holy hell did it teach me a lot!


Me too :(


Could you share some/all of your "never do again" and "needs to be done before launch" lists?


A lot of the don'ts are kind of domain specific (and the rest are kind of "don't do the opposite of the "do" column), and the majority of the "dos" are the kind of thing you always hear everyone saying, but once you've felt the pain it really drives the point home:

* Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind)

* have a deploy plan that is one step

* have a rollback plan that is one step

* have backups running way before launch

* have one-step restores from backup running before launch

* make sure your restores make their own backup before running (yeah... that day sucked)

* write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks

* document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!)

* make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!)

* Have someone that is not a developer use the app without any documentation (this is huge)

* Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work)

* build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable)

* Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with

* make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master

* plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here...

* stick to a style guide

* put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc...

And a lot more i'm probably forgetting...


I like this list a lot, and quite a few of these address real issues I've also hit in my career.

Quite honestly, I wish more tech interviews would focus on this kind of stuff rather than language trivia and "stump the chump" algorithm questions. It's 100X more important to the success of a project than how you would implement quick sort.


I personally wish that more schools taught this kind of stuff.

But at the same time, most of those things on that list many people would consider "obvious", but when the deadline starts getting close they start slipping (because shipping on time is more important than some stupid logging shit!).

Then before you know it you are a month after launch and you are drowning trying to figure out what the damn emails mean when they just say "The app won't work" and your boss is still pissed from the deploy you did a week ago that ended up taking over an hour because you never tested the restore system, and every few days you get a report of the whole thing crashing but you have no idea where, why, on what platform, or anything about it.

That's the kind of "lesson" that I ended up learning. Pushing the ship date back a week or 2 isn't really that big of a deal in 99% of cases. And having good ops in place, a healthy amount of testing and support code, and some nice documentation doesn't take that long if it's done at the start, and can save you a LOT of time and grief in the not-so-long run.


Thank you for this list. Most of it is indeed common sense that we've heard in other places, but I've favorited it to use as a checklist in the future :)


No Problem! It was kind of nice to actually write it down, a bit of an ego boost to really lay out things that I have learned!

I will give one warning that a lot of what I really learned is when to prioritise one of these things and when it's okay to let it slip.

Like should I push the launch date back 2 weeks to implement bug reporting? Is it okay to launch even though I don't have 100% test coverage? When should I prioritise writing tests for the remainder of the code? How much time is too much time to test a particularly difficult to test portion of code?

I don't really have answers or rules for those, but after living through each of them, I have a much better feel for what to do. And as always, shipping is better than not shipping. Code that you never release because you are always trying to make it perfect doesn't help anyone. At some point, good enough just needs to be good enough.


Never release on a Friday :-)


> Never release on Friday...

You say it like a joke but its actually very good advice. If you have a working app break over the weekend, it could be a disaster.

There's a similar axiom an old surgeon told me: if you can help it, never plan a surgery that will end when the working day closes.


But at the same time, wouldn't issues on Friday evenings have least impact on customers? Thinking around B2B enterprise companies.


There's nothing like realizing, that feature you polished like a jewel? When implementing it, you brought all the patterns and best practices to bear that you could. You archtitected the shit out of that thing! Yeah, no one uses that! That really puts things into perspective.


My favorite story about that is I created a really nice series of components in React. Fully functional, stateless, really nice clean testable code.

A user gets it, it's "too fast", the designer wants to put an animation in there to slow it down and help give some context. Of course the animation means that once you "clear" the dialog it flashes to blank before "animating away" (because it's a beautiful stateless functional component!).

So now the code is this hideous hacky bloated ugly solution, but it works...


The view is inherently stateful. Ignoring that because the JS doesn't have to be will always get you trouble. Adding transitions, however fast they may animate, will be killer.


I'm not shy of using internal state, but if I can get away with functional components, I will simply because of their simplicity and how easily they can be tested.

But it was just more of a story about how sometimes ugly hacky code is better. Because at the end of the day, you are writing this for the user, not for yourself.


And to realize that feature was never invoked because you forgot to catch an exception a few lines before it.. Yeah.


> C is the beginning of everything, everything is built on top of it.

I would argue that basic comp-sci principles and common language meta-syntax (mainly those derived from the fortran/pascal/c branch of things) is where everything (skills) should be built from.

I'm not expressing this clearly; I know that. What I am trying to get across is that if you understand the fundamental principles (not necessarily the deep-dark parts of comp-sci where wizards roam) - you can apply those to almost any language (save for a handful or so - there are some languages out there that look very esoteric; LISP for one, but there are others on the functional language branch and other areas where the mindset for developing in them is quite different.

That said, most of these "other" languages tend to be academic in usage (not that they aren't interesting in their own right!); that is, you won't generally find them much in the "real world" business area - not usually. However, sometimes you'll run across an employer or two willing to pay big bucks for that one expert developer to help them with their project in some language that isn't widely used. They are paying the money because the supply-demand curve is very skewed, but I would hesitate at taking such a position - while the money may be good, you could pigeon-hole yourself if you aren't careful.


I would add : Design-Ship-SELL-Support cycle :-) Nothing as enlightening for a developer to get confronted to user frustration in the Support phase AND prospect's indifference in the Sell phase


Apart form a lot of Legacy COBOL or Fortran (for proper technical computing)


The freedom to try stuff.

I started my "real" development career (I'd played around a little before then) while employed as an Admin Assistant at a company that used an Excel spreadsheet to track work coming in and out. Every task had to be repeated 4 or 5 times, as the company needed different views for different managers. Oh, and of course, only one person could use the spreadsheet at a time.

After a few months of typing this in over and over I got sick of it, and fired up Access. In the spare time I had here and there I put together a database everyone could use at once, input once, then open up appropriate views for different managers. I did a lot of this with the Access visual query creator tool. My manager was blown away when he saw it and gave me permission to keep building the feature set out - I'll be forever thankful for that, because many in the company resisted.

I added and added to that database, learning VBA for the more advanced stuff, until Access became too limiting (I honestly can't remember why now). We didn't have admin access on our machines so I couldn't install Visual Studio Express, but I could install SharpDevelop. So I did, and created an alternative front-end in VB.NET using the same Access database, eventually graduating to SQL Server (again, I forget why, but I think regular backups were one particular reason. I remember a phone call with a very confused rep from our outsourced IT provider wondering why an Admin Assistant wanted a SQL Server database).

Nowadays I work in Node, create iOS apps, all sorts - I've left that original environment far behind. But I wouldn't be anywhere near where I am today without those sandbox environments that let me learn and grow very quickly. People are quick to dismiss Access, VBA and all that, but they shouldn't be.


I think the lesson here is that if you give a motivated person a reason to build something, and access to the tools to do it, they will build it.

The same applies to game mods (minecraft now, warcraft3 years ago) where people love playing a game, get introduced to mods, and then make one for themselves. Each modding community has a field of experts with the same passion for the game as noobs. The experts produce documentation and sample code for the noobs.

The noobs have a "sandbox" to play in by modifying the game. First they follow tutorials or copy/paste code into patches. But eventually something remarkable happens when they start to modify that logic to accomplish their own goals. It's at that moment a programmer is born.

How many people started programming by modding games in a hex editor?

How about installing phpBB mods on a forum for your favorite game? That's how I got started.

How about editing jailbreak themes or tweaks?

Or running some metasploit module against your printer?

Or setting up your arduino to run Xbmc?

The common thread is that these are all sandbox environments; games, pluggable open source software, jailbroken phones, emulators, arduinos. Every sandbox also has a community of experts backing it and providing an invaluable service to noobs. These communities serve as an entry point for self-selecting, motivated autodidacts to gain exposure to programming. These are likely the people who become the most prolific, or at least passionate, programmers later in their career.


> The noobs have a "sandbox" to play in by modifying the game. First they follow tutorials or copy/paste code into patches. But eventually something remarkable happens when they start to modify that logic to accomplish their own goals. It's at that moment a programmer is born.

This is almost exactly my first programming experience.

I discovered GORILLAS.BAS [0] on our family computer and, after playing it for awhile, discovered that I could change things about the game by modifying the strange text on the screen. First I was changing colors. Then simple drawing changes. Eventually, I had a version that replaced the buildings with mountains and the gorillas with artillery guns. Gave it out on floppies to a few friends with simple instructions on how to play it.

It was at that moment that I realized I had created something pretty awesome. Never forgotten how that felt.

[0] https://en.wikipedia.org/wiki/Gorillas_(video_game)


Awesome story!

I had a similar experience. I was an junior accountant at my first job - I was tasked with combining a bunch of timesheets for several manufacturing facilities into one large timesheet to calculate payroll weekly.

I quickly grew bored of this and learned a bit of VBA to do automate the process, started learning RoR, Django, and moved on to technical jobs at other companies.

Funny thing about those first scripts I wrote - although they were relatively bugfree, they didn't account for having been run more than once per week. So one week when I was out of the office (and had run payroll remotely) a colleague ran the scripts and everyone was paid double. I left the company shortly after.


Just signed up to comment on how much I love this comment! It echoes my own experience too.

In my job after a period of learning and implementing the current processes, I wanted to make it better and my job easier. I did some Powershell scripting to begin with. Then I needed more so I started building C# WPF applications to manage and automate these processes. When I began developing it started out as merely a front end to some CSVs. Since then more and more people started using it and giving feedback and suggestions. It became a passion for me. I hit so many walls along the way and overcame them with internet resources and tutorials. Sometimes I would work weekends on this project. After many feature versions, bug fixes, and refactoring to address maintainability, unit testing and administrative/logging, it grew in complexity and users.


Play! This aspect of learning is crucial for children too, but as a developer nothing pushes learning like playing around with things that interest you.


> fired up Access. In the spare time I had here and there I put together a database everyone could use at once, input once… until Access became too limiting (I honestly can't remember why now)…

Didn't Access have a 20-or-so-simultaneous connections limitation? I guess it depends on how old the version. Yes, I tried using Access on a website once (Lowers head in shame).


I think you're right, but we were only a team of eight or so, so we never hit that issue. I also remember using two different files - one for data and another for the UI - that made it all work better. Sadly the details are lost to time now...


I miss Access. Superb RAD tool. Especially for small biz type solutions where you are replacing pen and paper, or "dunno".


I couldn't have put it any better. "The freedom to try stuff". People who provide that opportunity.


Oh wow, it reads like what I would have written as my story reads the exact same as yours.


A new job. I was an isolated developer for the longest time, first for a really tiny consulting company I started with a friend, then for a much larger company that was extremely siloed.

When you first become a developer its much easier to learn new things with just a little bit of direction. You may not always learn the best way to do things, but you're learning. Eventually I found that I hit a plateau. I was technically knowledgable and could learn new technologies fast, but the quality of my code wasn't changing significantly. I've found that this happened because the feedback loops for this type of work is much larger. It can take you years to see why your architecture is unmaintainable, because it technically works and is much more subtle.

The new company has hundreds of developers, all really smart. We do peer reviews for all new work, which helps you learn from the experience of others. We tend to work in pairs, some people do actual pair programming, some people just bounce ideas and questions off of their pair, and all code is peer reviewed. It's very informal and isn't really written down anywhere, more a part of the company culture. My pair works on other projects than myself, we each have a number of projects we lead, but we're both very familiar with each others projects and could take over in their absence. Helps us learn from the experience of each other.

The other big thing that changed with the new company is the writing of tests. Prior to this, I hardly ever wrote tests. Now, I write tests for any new code. Sometimes this involves TDD, and sometimes it's just test-heavy development. Again, we aren't dogmatic about this, and there's often code that is untested. This is usually parts that are unreasonable to test, or wouldn't benefit much from tests.


Similar story here and agreed, well said. Where I started, I was one of two developers at small-medium sized business. Because of the needs of the business, there wasn't a lot of need for more developers so room for advancement wasn't there, nor was there a need to expand my skills beyond what the day to day job required of me. The projects I worked on were very siloed as well.

Moving to a larger company with many teams of developers forced me to expand not only my technical skills, but my soft skills as well. Being able to work with many different team members, as well as across teams and with different business units forced me to improve skills that I didn't have the opportunity/need to improve on at my old job.


I relate to this strongly. I'm currently the only technical person where I work. I've gotten to learn a broad array of things, mainly because I had to. But it's very hard to go deep or know if I'm going in a good direction by myself. Even one other person to develop with would be a huge improvement.


As an older engineer, I agree with this completely. When I was younger the thing that helped me the most was working with more experienced, better developers.


This is so true. The company of just one good developer can make a huge difference.


Learning to take a breath. I learn to dev code by sitting in front of a computer and banging on a keyboard till it compile. I always felt like my code was shit because I was praying to the computer gods for it to just work. Then I read "Flash Boys" by Michael Lewis. In the book there was a god tier programmer that was a legend among his peers. He describe his way of coding was first writing the entire program using paper and pencil. Then he would sit down type it all in, and bam he would be done. I realize at my current level I couldn't do something so simple. I relied to much on my ide to handle simple task. It was causing a disconnection with logic flow in my head. So I stop just drawing boxes with class names and such on a white board, and start actually writing code on paper. It help me find small knowledge gaps, force me to remember little things, and reinforce what I know and don't know. The other thing it does is remove the simple temptation to bang on something till it works. We should be aiming to become software engineers, not grease monkeys. A engineer calculates and design a solution before he even attempts to make something. A grease monkey first thought is to hit it with a wrench. My mentor would tell me stories about going into meetings to design software where he would point out possible problems with the design they had come up with. Many of the programmers would disagree with him out of the box, but every time they would ran into problems right where he said they would be. This pattern always seem to repeat itself programmers would rather spend time with their keyboards then a white board. Taking a breath thinking about the problem calculating what is needed design and test a possible solution then actually attempting the solution is something truly difficult to do. Current state of programming is like asking a kid a math problem Me:"Timmy whats 1+2?" Timmy:"1?" Me:"No, whats 1+2?" Timmy:"2?" Me:"No, whats 1+2?" Timmy:"3?" Me:"Correct, next problem".


> We should be aiming to become software engineers, not grease monkeys. A engineer calculates and design a solution before he even attempts to make something. A grease monkey first thought is to hit it with a wrench.

That is very inspiring. Thank you!


I am still in college but all throughout high school I hated taking programming tests on paper. When I read that book, that same example stuck with me as well. I no longer complain about it and learned to see its value.


Practical work. No matter how many books you read, if you don't practice it you won't learn it.

Also a very important thing that I've learned over the years is that the difference that a Developer has and a Junior Developer is the confidence that he/she can succeed the task handed to them.

I personally as a developer, think that I can achieve anything you give me task wise, no matter the technology involved, I'll just learn it and do it. The time etc of course will vary and if you give me something hard that is out of my current profession it might take a lifetime to complete but my confidence that I will get it done is what makes me a developer (I believe).

Once you find the confidence to call yourself a developer then you'll be a developer.

Note: That leagues of developers vary a lot. I'd consider myself a very median developer, and I've seen others that are doing crazy things, that doesn't put me down. I am as valuable as they are, one person might be lacking a bit on maths but might have a better artistic side and the opposite. Generally over the years you will see people doing things that you think it would take you a lifetime to do but its just who they are. Don't lose confidence, your skills will be as important as the other people skills. Personally I combine an artistic side and as a median dev I can create nice mobile apps and websites and work both on the backend and frontend of things and thats helping small companies that employ me to get a kickstart. If I was to go to google, I'd prolly fail all the interviews and people there would be a lot better technically, but again they might not be able to bring the same skillset that I bring to those small companies. So by saying that I believe everyone is different and anyone can find a fitting place as a developer.


As a further point to this, I found myself in a trap with work for 2 to 4 years where I would often spend ages mucking around before actually starting it. Because I was worrying I'd get it wrong/not be able to do it/not sure where to start. Perfection desire, whatever. Another great time waster was refactoring parts of the system (which I still do today, but a lot more strategically).

If a project is 4 weeks long I'd spend 3 weeks basically pissing around and then 1 week blitzing it. I mainly got away with it because I was smart and fast, but got in trouble sometimes when they'd be a surprise "show us where you are".

Somewhat ironically, the best thing to cure this is to make a bunch of stuff. Make a prototype as fast you can. Make the prototype outside the existing system if it's complex. This especially holds true for things in web programming where a lot of things can mesh together as well as you needing to make an input form in HTML that might need to be complex and then suddenly you're dealing with how you'd make X complex control in javascript and dynamically load Y from the database. Ignore that complexity for now.

An example is if you need to make an integration with an API, muck around with the API in an isolated console app first. Hardcode the input params, don't even bother accepting arguments. Manually change them and re-run to test different inputs. Roughly map out the API, then cut and paste the bits you want to keep, rewrite the bits you don't. If you're a junior and don't know how to make stand-alone apps, learn, it's easy (you'd be surprised how often I've come across this, junior web devs only knowing how to write something in ASP.Net but not knowing how to make a simple console app).

Another trick when I'm really prevaricating or avoiding some particularly nasty or boring code is to write the code in comments. Delete each comment as you've replaced it with real code. It's usually enough to get me started. I even often write just a few comments and then because the design's finally clicked in my brain start writing the actual code in impatience to get it done.

    //set the start date to start of day
    //set the end date to the end of that day
    //foreach thing
    //  parse the param
    //  validate param
    //etc.
Naming can also be hard, if that's getting you stuck, call the method "DoThing" and write it, then you'll usually know what to call it by describing what it does.

Or focus on getting one bit done. If it's a report, I always write the SQL standalone first, use a bunch of hard-coded params at the top of the statement that I can comment out when I copy it into the method and start parameterizing the query. Then I write all the scaffolding around it. If it's something that's got complex back and front-end code, I get one bit of it roughly working before the other (usually the front end with a dummy object), I don't attempt both at the same time.

TLDR; Stuck? Break it down in to chunks and tackle the smallest thing you can to get you started.


There are many good things mentioned here already, and I would like to add one that might not seem that obvious at first. Teaching. I once read a book (about C#) that had the following line in it: "Qui docet, discit - He who teaches, learns". This line stuck with me since then.

Now, many years later, I can reaffirm this. Teaching others something requires you to understand whatever you are teaching them, and even though you think you already understand something, when you teach it you force yourself to communicate it in an understandable way to others. In addition, you sometimes will have to do some more research to learn more about what it is that you will teach.

I started blogging about a decade ago, mostly about things that I found were interesting and then decided to actually dive deeper into the subject, and then write up a blogpost to explain the subject in understandable pieces.

Later in life, at university, I did some teaching of students whom struggled with several programming courses. Once again, I learned a lot from this. Sometimes they had questions that I never would have considered and then had to look up, to explain it to them in the next lesson.

And now in the industry, where I work, we give "devtalks", we can talk about anything technical we want and teach it to the others (whomever attends, but usually attendence is about 50-60 people). I like "going deep" in technical things, so I force myself to "go deep" and learn more about what I will talk about and then once again, present it in an understandable way.

---------

This is maybe not the thing that let me grow _most_, but I would certainly say it is a valuable addition on the road to become a better developer. And besides, the other commenters already hinted that there is no "single thing" that let's you grow most ;-)


The botched cliche we have now that's says "those who know, do. Those who don't, teach" was originally:

Those who know, do. Those who understand, teach.


I have a unique view on this I believe. I'm originally a chef(in fact in back to it now).

A lot of the comments I see align with how myself and my apprentices have grown.

It starts with fear. Being scared of screwing up. Then comes the first epitome. I can do this.

Then the new scare, shit I don't know this, I'll fake it, overcompensate and assume I'll pick it up, or research it quickly enough to look like I know what I'm talking about.

After that(eventually) it's acceptance that I have more to learn.

For me, as a chef, it was a few, months ago.

(Well it was the 3rd time honestly). I don't know everything.

Now to put this in perspective, I have been head chef of 5 star restaurants in Australia. Some of the best of the best.

My realisation point was finding out someone who could hands down push out pans dishes both faster and better than I could.

I have been doing this since I was 16, and my parents were chef's . I assumed I knew everything.

Since then, I have spent a lot of time watching them do what they do, and how they do it.

Now I'm an amateur programmer, I can do it PHP, MySQL, c# and vb.net, and I spend a lot of time googling, but I think the two industries cross in base learning more than price expect.

The point when we are challenged, not by difficult jobs, but by people who know more about that subject, is when we grow. If we take it objectively.

If we assume our training is bad, or were not good, we fail.

That's my 2 yen


As a chef, how many hours a week do you work?

When you come home after working, do you prepare your own food?


I try to not work during my splits. So I'll work 940am until 2pm, go home or the gym until 5pm then finish at either 10pm or 11pm. 6 days a week.

So about 56 per week. I try to take every second Sunday off.

During my split I'll prepare my wife's dinner, (cooking it if I can ahead of time), on my days off I enjoy cooking for friends and small parties.


I love this, you know you are truly passionate about something when you quite happily spend every waking minute of the day doing it.


I realised I was when I took 4 years off. Man it's great to be back.

On a side note, I love how easy it is to support your passion now. Between Instagram, blogs, YouTube and ebooks, I'm making combinations I would never have dreamed of when I was an apprentice.


The times I've grown the most are when I've jumped in the deep end. People aren't hiring you for your coding, despite what they might tell you. They're really hiring you for your problem solving ability. So don't worry about it.

The times I've learned the most are when somehow I've ended up in a job where I know nothing. I might not know the language (this is how I ended up learning things like C# and python, java, etc) but just keep searching and reasoning your way through it. If you're new to something, you'll be learning lots of things left and right because it's all new to you.

Same for jobs (different companies do things differently), people, projects, etc. Getting around and trying more is really all you can do to get that real world experience. Just don't be afraid when people say no. Or find a place where your deep knowledge can help them, and then you can also pick up some of the other things they do.

It also sounds like you don't interact with a lot of other teams or codebases that may exist (or may not) at your job. Maybe offer to try some of their easy tickets to just get acquainted with it? (your boss might even love that you care)


Landed a contract to develop a SAAS system. Quoted 4 months to delivery. About a month in I realized I had made a terrible mistake and would likely need 6+ months. But I had already been paid 50%. I just started working 18 hour days for the next 4 months (I ended up delivering 1 month late).

The code was not great but it worked and still works with no issues 3 years later. I get a nice check from it every month but try to not look at the code base because it is horrifying.

I learned a ton though during that time. Fear is a wonderful motivator.


> Fear is a wonderful motivator.

I'm convinced this is part of what drives home so many "oops" lessons for me and helps me figure out what I can do to mitigate them in the future.

For example, I learned the value of caching when we launched a client's site on a nationally televised show. We didn't have caching and when tens of thousands people hit it after the show's host mentioned it, it went down. Just as we got it back up, the show aired in central time. Boom. And

That was a bad day but I will always remember the value of not just writing code and delivering a website, but trying to understand how it will be used and in what capacity. And caching. Always caching.


Luckily caching is not one of the two most difficult things in computer science :)


> Fear is a wonderful motivator

Depends on the person. I find that getting good sleep, vigorous exercise, and a clear direction works much better for me.


>Fear is a wonderful motivator.

For me, deadlines are a motivator. I'm a horrible procrastinator but I do my best work right before a deadline


> Fear is a wonderful motivator

:) Experience is the bag of s*#t that we carry with us. There's no teacher like dealing with real issues. And if you survive them you're stronger.


Empathy. The ability to understand and share the happiness and frustrations of your users and fellow co-workers helped me break barriers as an engineer. It helps me become more open minded to suggestions and at the end of the day, I am confident that what I'm building makes somebody's life better. Also, empathy towards your coworkers who will eventually be working with your code will continuously inspire you to write good and manageable code.

If you believe that you are building something you are proud of and writing code in a way that your co-worker appreciates, then you are a great developer. If anyone tells you otherwise, have an open ear and ask them why.

I teach people how to code on the weekends and I can confidently say that the ones who are more considerate and understanding tend to pick things up a lot quicker.


This answer certainly fits the current social fashion, but I don't find it convincing. There are many, many horrible/aspiring developers who are focused empathy and feelings but just aren't good at building things.

The strongest developer I've ever met was on the aspergers/autistic spectrum. Empathy absolutely is a boon in life and in work, but it's neither a guarantee nor a primary driver of success in technical fields


Ive met my fair share of talented developers on the aspergers/autistic spectrum. While technically sound, they seem to lack the ability to react to time sensitive situation and hack things together in a short timeframe. Also, the best code might not necessarily be the best option. Its okay to push imperfect solution and let junior developers make mistakes so they can learn and grow.


Write your own code, get feedback, read others code. Repeat them all again, and again.

At an earlier stage, building my own sizable project helped me the most. I still remember writing bunch of Java code in the middle of Iowa when I was an exchange student, which ended up helping a lot of my friends course registration in my university and got great feedback about the UI of the program. I learned a lot, especially about all the basic system building, and the best thing was that it gave me the confidence that I am capable of building something useful.

Since then, one of my weekend hobbies was doing some fun project that does not need a whole lot of effort -- like making a simple dashboard for the family in Ruby, building a home automation bot in Go, writing some my own investment tool in Python, etc.

It's just the same as picking up another language or any other skill: there is no one path people learn it. The way I learned English was mostly by reading many books, and many other people learn a second language mostly by watching TV shows or talking to people. There is no set path -- although there may be necessary things people would need to do regardless to achieve high-level of mastery, like talking and reading in a language -- but one thing necessary is an incentive, especially a positive one, and building confidence over time.


Ah, I forgot talking about reading others' code. Reading good code is important. Understanding good design is important. I've read tons of Linux kernel code, source code of Linux packages, golang code in github, etc.

Also, there are many books that discuss software design. The one that helped me most was "Principles of Computer System Design". Not all the parts are great, but reading the first few chapters & recommended books changed my software writing.


Introspection and mindfulness. Learning how my mental state and well-being affects my productivity.

"Practicing Mindfulness: An Introduction to Meditation" [0] was very helpful even though I don't practice meditation.

[0] http://www.audible.com/pd/Self-Development/Practicing-Mindfu...


Me too! Understanding the way your state of mind affects your ability to reason makes a big difference


"Proper CS degree" is really not relevant to your ability to write software. What I learned in CS was completely irrelevant to my job, and to the jobs of most programmers. You can do things (computer vision algorithms) that I cannot. I'm sure I can do things you can't. That's fine, software is a team effort, with different people taking on different tasks.

The issue isn't formal education, then, it's breadth of practical knowledge.

The thing that has helped me most, at least in that realm, is getting bored easily. Once I learned a problem space enough to be confident in my skills there I get bored, and move on to something new. Learning something new always involve discomfort and lack of confidence and "I don't know what I'm doing." So to mitigate that, you can try to pick somewhere that is adjacent to your skills.

E.g. maybe you can switch jobs within your company to working on the platform itself, so you learn a new set of tools and problems but still in same programming language. Or find an open source computer vision library and read the code and learn the tool chain, build some toy projects with it. (Contributing without work's permission might violate your intellectual property agreement, depending.)

More expansive thoughts on choosing something to learn:

* Choosing a technology: https://codewithoutrules.com/2016/04/27/which-technology/

* Choosing a side project: https://codewithoutrules.com/2016/09/09/side-projects/


Studying formal CS is useful to learn the breadth of software solutions, as well as to understand the underlying shared theoretical grounding. It makes it easier to know what solutions to explore, and to learn what you need to learn. But I agree that it didn't add much value in the actually learning to code department. The best way to be better at programming is to read and write a lot of code.


You can learn most of it nowadays online from sites like Coursera, edx, Udacity, and Stanford's Lagunita.

The only exception might be discrete math, but pick up a copy of Rosen or Epps and some Schaum's Problem books and you can pick that up as well.


As a programmer: trying to learn to program in a functional programming language after years of writing imperative code changed the way I wrote code and the way I thought about problems. As a developer: working at startups helped me learn a broad range of things around my code: how to test, deploy, harden, etc. You are also able to see the entire product you are helping to build rather than at a larger organization where you might be assigned particular tasks.


I built a programming language. I was inexperienced, winging everything, but I wrote the parser, interpreter, runner and virtual machine. Then I tried to make it as fast as possible. This accelerated my learning more than almost any other project I've worked on, and taught me things about profiling and optimization that I use in my career every day. I hit nearly every aspect of development in one fell swoop, and I look back on that time quite fondly.


Would you care to share the source code, if it is hosted publicly? I've been building a programing language as a side project and I'd like to draw some lessons from others.


The code is so gross and not runnable at this point that I wouldn't feel comfortable posting it. I can share the source with you though if you'd like. It's all c#. dested at gmail


Are there any resources that you could recommend for someone else who's just starting out and wants to tread the same path?


What ndh2 said. Don't try to follow a tutorial on how to do it, just do it. If you know how to use substring and indexOf in your preferred language you can write a parser. If you know how to use switch case you can write a virtual machine. Boil it down to the most basic parts and just keep going.

It may be daunting at first, but its not magic ;-)


I don't think there's going to be a book for "winging everything". Just do it!


>For the last two and a half years I've been developing computer vision algorithms for a proprietary embedded platform in C.

Congratulations, you're a developer. That's already miles ahead of what your typical highly-paid web developer writing CRUD apps does for a living.

To answer your question though, I suppose you're truly a developer when you have the mindset that you can learn anything required of you to get the job done.

My advice: pick a language highly dissimilar from C, and deep-dive on it. Then do it again with another language. The confidence you'll gain in the process will be tremendous.


Independence.

For me, I've always had the privilege of being a lone wolf, because I only accepted remote gigs as a consultant as my primary goal was always generating revenue on the side through programming business ideas, trying them out in the wild, falling on my face and getting up, some things worked some things didn't but it eventually freed me up to only focus on my ideas as the revenue kept climbing. This independence forced me to be practical and efficient while focusing on hardened architecture, doing the work of many as an individual simple because there are less decision trees so things move very quickly.

There is a huge value in gaining experience and knowledge while working with great individuals in teams that make you better for sure, not discounting that experience at all. Just personally, I get very uncomfortable when people dictate practices to me that are highly crufty and theoretical so I'm much better suited going at it alone because I can't shut my mouth about those things and end up pissing people off.


For me it was pair programming, without a doubt.

A year and a half ago I moved from a large enterprise to a small consultancy who practices pair programming. I've learned a great deal more in that year and a half than in the preceding five years working solo on agile and not-so-agile teams.

Good practices and spending time attacking problems together with various colleagues across different projects and tech stacks is what has gotten me to that next level. I'm completely sold on the practice.

I'm much more productive while working with a partner than I am solo as well.


I guess this depends on the stage of development for me.

As a beginner the "one thing" would be getting a job. When you're beholden to someone else you lose the ability to freely cut scope whenever you're uncomfortable. Thus, I became acquainted to a "learn or fail" mentality.

Eventually I got stuck in the intermediate developer quagmire - basics are too basic but advanced concepts are too advanced. I knew I needed to learn more but I didn't know what I didn't know. Not to advertise, but Hack Reactor helped me clear this hurdle really fast. I walked away with a greater understanding of how to actually comprehend documentation and assemble applications in addition to the domain-specific material that was taught.

Now that I'm doing more meaningful work (though I'd hazard calling myself a "senior") my biggest growth points have usually involved having applications people actually rely on. I am my own pager-duty, so if I want comfortable weekends I need to write architecture that is capable of recovering gracefully from failures, errors that can be read by programmers or designers, etc. Answering to my users has helped me realize new ways I can meet (or exceed) their needs, areas where I was sloppy and should've handled better, and all sorts of things in-between.

I'm looking forward to the next point in my career that I take a significant stride in my growth as a developer.


> I'm looking forward to the next point in my career that I take a significant stride in my growth as a developer

and what would that be ?


While you asked for the one most important thing, here are many. The one most important for you is the one where you are currently lacking the most.

1. Being able to code well. This amongst others requires (a) Giving a high-level structure to your code, way more than what a programming language and tooling enforces, and (b) Being able to maintain a "stack" of what you are doing at any time as you think at different scales, down from what to name a variable, to the project goal.

2. Think of a project idea of your own. Whatever it is. And then make it. You may realize very shortly where the gaps are, in your own skills or in the state of the art in technology. Having a good knowledge of both, the possibilities and limitations leads to a better understanding of how to do what is practical at present.

3. Master presentation skills. These are useful not just in presentations, but in all communications. I recommend taking formal training or reading a book or two on this. Like everywhere else, training and coursework on this often misses the point itself. So pick carefully.

4. Be watchful of opportunities as well as politics at the workplace. This point may seem out of place or obvious, but it may end up being something of critical importance in your actual growth path.

5. Last but not the least, know what you want to do, though be always prepared to adapt to the changing industry needs.


Could you recommend any books that you found particularly useful?


I learnt presentation skills primarily via experience. However, later skimmed through a couple of books. Search for Jerry Weissman, I found his book quite good. There would likely be many more (which is why I did not name any in my parent post), so you may want to research yourself a bit also.

Edit: I assumed you are asking about a book on presentation skills, since that is only place where I had mentioned books.

I have also come across a good book on surviving corporate politics, that taught things I had learnt the hard way. I do not remember the name or title, but an Amazon search should help to find a similar book.


End-to-end responsibility for a mission-critical system without which the company I was working for would have gone under in less than 6 weeks. Lone developer also responsible for workstations for roughly 30-40 employees. It was a wild 18 month ride but it was good schooling.


Ha love that.

'I know you're the guy saving the company and all... but my printer is jammed can you take a look?'


That was the lone task I abdicated. I do not work with printers. Horrible peripherals. One would think that the oldest peripheral was best understood.


I hear ya, I also have (P)rinter (T)roubleshooting (S)tress (D)isorder. Wearing several hats is great, but having to support internal and external customers with printer issues (my main job was programming the company's flagship product also...) almost drove me to start farming potatoes somewhere far away. Brutal does not start to describe it.


I am amazed that printer companies can get away with simply not releasing drivers for old printers. Pay a couple grand for a printer and then when the latest OS comes out the printer company says "sorry we can't give you a driver for the latest OS"


I also have that form of PTSD. Funny war story, I have a small sized scar on one of my fingers because I put my fist through my last home printer. And I consider myself a pretty calm guy...


You will enjoy watching this then: https://www.youtube.com/watch?v=N9wsjroVlu8


This! For me it was almost the same as well. Being responsible for a full system, end-to-end which included learning Elasticsearch, deep diving into Django to integrate some complicated search forms, setting up and maintaining servers.

What I've learned is it's about the amount of responsibility you get. If you're responsible for something, ideally something critical to the product, you learn a lot delivering that product. That's how I grew anyway.


My project was Django-based as well :D


Getting enough sleep. Seriously, it makes a huge difference.

You're able to make better mental connections and decisions when you're well rested, ultimately leading to growth as a developer.


This. For the past three months I have finally been consistently getting 7-8 hours of sleep a night and I have noticed a drastic increase in my productivity, retaining of learned skills, and growth. The hardest part is going to bed at midnight when I am in the zone on coding a side project, but knowing that I will be able to take full advantage of the following day is something that took me years to finally understand.


3 books I read a couple of decades ago, they were talking about technology of a decade before that and felt outdated but were really helpful in raising my powers as a developer: 1. About face 2. Writing solid code 3. Code complete I still recommend them to young developers and bought a paper copy of them for myself. The ones I read were left at the company I worked at at the time. I had an expenses account and most of my expenses there were on books.


What did it for me is not repeatable today. Started working as a developer in 1981: my first decade and a half or so without any stackoverflow or google or web or even open source code. I had to learn everything myself (other than the occasional book, article or journal). Of course I have no desire to do this again, but it forced me to become inventive and creative instead of just search-copy-paste-ive.


My story is pretty similar and I agree with your comments. If I had to sum it up as "the one most important thing", it would probably be "curiosity".


> So in short I'd like to ask, what one thing let you grow/learn the most as a developer?

Presenting at conferences. Being able to distil your work into 15 minutes is a huge skill. It forces you to think about the problem, how you explain it to people, and how to convince them that you're right.

You don't have to be great at the start - find community events which are welcoming to first time speakers.

I guarantee there's a meetup somewhere which is interested in vision algorithms.

At the very least, you'll have some smart-arse come up to you and explain why you're wrong. At best, you'll have people coming up to you with helpful suggestions.

As a bonus, being an active and visible part of a community is an excellent way to find your next job.


Always bite the bullet.

Often you will know that a piece of code should be refactored or needs better tests; or tests at all. It's always tempting to not fix stuff or rewrite as you go because this isn't the core of what you've been asked to do. If instead of taking the "easy" option you are constantly making the code better and simpler you will by definition be a better programmer.


You're in embedded computing. It's a very different world. Don't judge yourself based on the JavaScript world. It's just not relevant to what you do. And forget the degree. Again, not relevant. Now to your question:

Write a lot of software. Get code and architecture reviews from people with a lot of experience. Look back over your own code with an eye to editing it. Where can it be tighter? Where could you avoid a class of bugs by putting in a few habits?

Read a lot of history of computing, especially off the path that led to your primary tools. It provides a wonderful perspective.

And now the weird one: learn applied behavior analysis. It gives you the underpinnings for reasoning about the behavior of humans and animals.


Write your own projects (ultimately written for others) in several different languages and follow your intuition. Growth is natural and unforced when it's driven by intuition and curiosity. It should never be forced or driven by comparison with others or the need to prove yourself. Even the most abstract things we do as humans are at root emotional journeys, so you need your emotional life to be healthy to grow. And learn several languages: C (you have, which means you have C++, Java, C# etc), LISP, Smalltalk, Python, APL, Forth etc, oh and math. Also, it never ends and you never "get there". Everyone is constantly learning and you cannot know everything.


Writing my own games. You can start out simple to get your feet wet, but sky's the limit for what functions and features you could have and need to learn.

Think of a simple pong clone. Add better AI. Maybe make a selectable difficulty of that AI. Make a GUI menu for that. Add touch or mouse controls. Add network multiplayer. Simulate better physics. Add sounds and background music. Online high score list. Etc.

Each of those requires increasing your breadth of knowledge, and doing them well will require some depth, too.

The second part of my answer would be to not get caught up in perfecting any of the above the first go around. Iterate, learn, improve.


If you don't want to swap jobs, another way to get very good exposure is to deep dive into any external code base you have access to.

I was a sole developer for a time, but we had the intention to grow. In preparation I spent a lot of time cleaning up an old codebase to best practices. I pushed every tool and library we used to the limits to get maximum benefit/introduced complexity, which meant reading and understanding the source.

My go to language is Scala, and I learned a huge amount from SBT, akka, slick, play and others.

Were now up to 4 developers with no official hierarchy, but its agreed that these investments have paid of.


Working in a team where the senior engineer let me fail.

We were working on a fairly large new system and I had an idea about how I wanted to do something. We discussed the pros and cons and afterwards he sat down and said to me "If you do it like this you'll have problems when you want to refactor it in the future, but if you want to do it that way go ahead". I went ahead and did it my way, he was exactly right and I learnt a very valuable lesson in application design, architecture, and how to lead people in the future.

I like to think that now in all the teams I lead that failure is always an option.


A mentor. The company I was working for hired a new developer and he shared tons of information with the rest of us, including showing us how to do things his way. Even if I don't do it all that way, the things I learned improved my code way beyond all the stuff I'd done before him.


>So in short, I'd like to ask, what one thing let you grow/learn the most as a developer?

Writing (33%) and connecting with people (33%) is as important as coding (33%) - being able to program alone solves 95% of the 33% coding pie (being able to understand advanced concepts solves the other 5% of that 33%). You will never be "confident enough" to call yourself a developer. I have a BS degree in CS and I sweat my pants when it comes to code interview. Everyone has some sort of impostor syndrome. Write about what you did, and see what channels could connect you with the people who might be interested in what you do. There are always people interested in your work, no matter how stupid your project sounds to someone, keep in mind, [a person who isn't even good at playing games but has an anime voice](https://www.twitch.tv/nyannersz) has 250K people paying her every month to do it. You don't have to shill and spam other channels, but your intention and code, if not published are just your shit, no one cares.

Connecting to people doesn't have to be face-to-face. What I learned myself was that the Internet made it incredibly, incredibly easy to get to a very good person in the field who are willing to talk to me, even if I'm just not "very good." Opportunities will come to you by connections to such people.

Also, I think coding/writing/networking is like going to the gym, the returns compound.


Professionally, what helped me grow the most was taking larger responsibilities within my project: overseeing a framework/middleware change, redesigning the technical architecture and rewriting the deployment tools. I learned tons of stuff and expanded my comfort zone. But obviously you have to be in a position where that's possible.

Personally, working on side projects. I've started quite a few of these, but never had the patience to go through with them (or I stopped working on them as soon as they were good enough for my needs); and one day I discovered projecteuler.net and fell in love. The goal is to solve mathematical puzzles by writing programs that run under a minute. It tends to be short programs, and you have to have some mathematics skills. What I got out of it:

* finally putting my CS classes to use: when you're working on large numbers, which is usually the case in PE problems, you immediately see the difference between a O(nlog(n)) and O(n^2) algorithm - one finishes quickly, the other hangs your PC. It really gets you thinking about the efficiency of your programs, how much memory they will need, how you can optimize them...

* learning or practicing common programming tactics such as recursion, DP, memoization, etc.

* learning Python: writing short programs is a great way to understand how a new language works.

Obviously PE problems are toy programs, you won't be learning much about how to architecture your code or use a given framework, but it may help you build your confidence on CS topics, common algorithms, and math knowledge (which I feel more developers could do with).


In a word - context.

This might sound a bit counter-intuitive, but learning how to break things has helped me the most in learning how to create things. I'm not at an absolute expert level in the IT security field, but it's the thought process that has helped me build a deeper understanding of how things are developed. From this, I have learnt and continue to learn how to think critically about whether a particular design for a piece of software I'm trying to break is good or bad, and also think about what I would have done had I been a developer.

I guess in a sense, it's me asking myself the question of how I could personally design quality software at all levels. Getting into the nitty gritty details from learning how to break things has really helped me learn more about development at all levels. From the low level, where, say, Java might have a function that could be used inappropriately - questioning why they were designed that way. To libraries that have issues - questioning why the developer used this library. To the high-level, the overall pieces of the system - questioning if they interact with each other in a logical way. Then there's also the user interface and experience aspect.

So, understanding the reasoning behind choices and why things are the way they are (from the level of the C programming language, to the libraries you use, to how the users expect to interact with it, and what other developers would expect if you want them to contribute to it) is the one thing that has helped me become a better developer. It just so happens that in IT security, you tend to ask yourself and the developers you're working with these exact questions.


I built a project to the point where I could demo it to people (search engine for lectures)

https://www.findlectures.com

I don't think it matters what you build, but a larger project gives confidence and much broader knowledge than you'd get in a work environment. Finishing bigger projects helps you build software engineering skills that are valuable but hard to develop otherwise.


That's a really awesome project! Have you written anywhere about the process/challenges?


I started writing up an outline / notes for a talk, which you can see here-

https://www.findlectures.com/articles/2017/01/22/Software-Ar...

I think there is a fair amount of detail there, but if you have questions I'm happy to elaborate :)


Thanks! That's very interesting in itself, and there's way more going on than I first realised.

Apologies if I missed it, but what's your general strategy for crawling? Is the list of sources curated or are you looking across the whole internet for content?


I'm curating a list of sources - that makes the dataset easier to deal with, and I think higher quality.

In a lot of cases I'm trying to rely on someone else having vetted speakers. E.g. a conference picking speakers, universities hiring good professors, someone recommending a talk on hacker news. I also boost the ranking if a speaker is interesting enough to have a wikipedia page.


Interesting. Thank you!


Changing jobs.

I don't have a proper CS degree. In my first job, I was writing software based upon what I went to school for, because I happened to also know how to program. I kind of felt the same way you did. I was there in one capacity or another for about 4 years.

I had to change jobs for various reasons, but when I did I learned a lot of new things in a very short time. Skills and knowledge are important and I learned a lot of them, but most important thing I learned is that I'm actually a lot more capable as a developer than I thought I was. That's been very important for my growth, since I have confidence to attempt all sorts of things that I never did before. I would have done it a year earlier if I knew exactly how employable I was and what it would do for my skill level and confidence.

If you feel held back by the work you're doing, I suggest you change jobs. If you're not and you like where you work, then the next best thing to do would be to start a side project that doesn't have much to do with what you're doing now. That's harder but it's a way to pick knowledge up.


I studied for a Master's Degree at Northeastern, and their introductory Computer Science class, which was referred to as "Boot Camp for Master's Students" and was designed to bring us all up to a common level of programming knowledge, was taught in a Scheme variant called Racket.

I already had several years as a software engineer, but I was shocked at how much programming we did before we got to the "mutating assignment" statement: set!.

That class and it's follow-ons in that program did a lot to expand my mind about programming and thinking about data. I later used the curriculum to introduce several other self-taught programmers like you to a more rigorous, data-oriented way of thinking about programming.

You can work through the curriculum yourself here: http://www.ccs.neu.edu/home/matthias/HtDP2e/

Career-wise, having 3 years of experience and a Master's Degree in a hot programming market like Boston opened a ton of doors for me.


Yeah, if you only worry about the "core" of what your job is, you're not going anywhere

Why are you not testing your algorithm in your computer? Load pictures, make it run through your functions, see the result there. That's why you have ifdefs. Then you can use libraries, malloc, to get to the point where you can test it

Why are you automating anything in bash? In python? yeah

Doing parallel projects help


I think one of the things that really enabled me to grow as a developer and as a person was to accept my limitations and still be able to call myself such things as "engineer" (the role I currently perform in at work) and "mathematician" (what my degree is in, and what I heart to continue learning)

I think these arbitrary and frankly elitist constraints on what it means to be something like an engineer is often time more bullshit than not. You _are_ a developer. And you might even be better than you think you are given you've had to work with a very difficult language with extremely difficult constraints. Personally, I have no idea how I'd work in C if I didn't have access to malloc, free, or a lot of the components of the STL. The fact you're still looking to grow and expand experience rather than settle into dogma and specialization shows a lot of maturity.

If you needed an official welcome: Welcome to the club. We're all different here.


It's like anything else -- you grow the most when you work outside your comfort zone. Be able to accept failure in these projects but keep at it. Personally I grew the most when I was forced to do things that I simply wasn't prepared for but where failure would be very painful. This isn't great, but it is wonderful for focusing the mind.


Autonomy. I have only really ever had one opportunity to do whatever I wanted to the codebase. And the motto for our team was to make the best code that no one will ever see. With no goals other than "meet the customer requirements" and "make the code better", I had a lot of opportunity to improve on my ability to improve code in situ.

Beyond that, job hopping. I have written software targeted at other software professionals, physicians and nurses, lawyers and paralegals, military and coast guard pilots and ground crew, rocket scientists, and military paperwork bureaucrats. Each time, it stretches out the arms of my "T-shape" a bit more.

Nothing hurts me more than someone telling me that I can't work from my own initiative. "Do this, do it exactly this way, and do no more." That's guaranteed to stifle my personal growth, and to preemptively discard much of my expertise.


this was so many moons ago: I worked in an organization where I received a 'best contributor' award that year. Then my manager called me in to discuss a potential large project in the business. I was to go and find out what "they" wanted. For many months I worked with all kinds of business entities, learning about the requirements and how they operated, and about the core mission of the company itself. I was still the developer for this new project but what I did was architecture, it turns out. I knew nothing about this field and I learned a whole lot while working with many teams creating an architecture that I can communicate. I did little coding and the company started hiring as the project took shape. It was a turning point in my career. I never stopped learning about the innards of coding, it was and is an essential know-how in whatever aspect of development one gets into.


Learning about functional programming.

It changed how I think about writing code by exposing me to new ideas and shining a light on my own bad habits picked up while learning by doing without understanding.


Time. My 19-year-old brain was fully capable of front-end development, but absolutely not ready for some of the more (relatively) complex computer science topics. I just hit my 30's and can feel my capabilities expanding more with each passing month. I wish I was capable of learning at this rate/depth earlier in my career.


Just want to reiterate the comment at https://news.ycombinator.com/item?id=13782032 and say that learning specifically statically typed functional programming totally changed me as a developer. It opened my mind to the semantics of programming languages and to the design of programs in the small and in the large.

If you're writing C, then you're a developer, no doubt about that. But if you're interested in the 'meaning' of programming and software engineering, then I highly recommend learning functional programming. Here's an excellent course: https://www.coursera.org/learn/programming-languages/


I've got three things. The last is the key in a "I know more now" sense but the first two provide the framework to let you go ahead and do it or hold you back.

Confidence. You are only as good as you let yourself be. Believe in yourself more. Don't let your worries block your development.

Forgiveness. Forgive yourself for mistakes and not knowing things. As that DHH viral Twitter thing showed, even the best and most productive developers Google the basics all the time

Challenges. I grew the most as a developer when I had to do something and I needed to get something done. Be it a side project, new job or saying yes to something a little out of your comfort zone, challenges help you forge ahead with purpose.

It's often why books and courses don't get you that further ahead on their own. It takes that need to fix x or implement y to really develop


Books and courses work alright imho if you're learning in the face of a challenge or with a specific goal in mind.


I work at an indie ISP. One of the biggest growth opportunities I've ever had was when my job gave me a bare-metal server in one of our datacenters.

It was sitting in the junk pile, with a cash value of maybe $700 if we were to sell it on ebay. So I asked if I could use it, and they set it up for me.

I had never configured `/etc/network/interfaces`. I had never used the `ip` or `route` commands. I never knew what would happen if you tried to `traceroute` when your gateway is misconfigured.

Now I've done all of those things :)

For me, any opportunity to get my hands dirty on something I've never done before, I jump on. I have taken jobs because of that one criteria. If I'm not growing at my job, I either take action (talk to my boss) and make sure I get new opportunities, or I start looking for another job.


Concieve of and work on your own projects. Make things that use software. Scratch your own itches. Eat your own dogfood.

Make things. Make things. Make things.

Not just pieces of things, the full things!

Don't get trapped in over-specialization, always be able to make things completely.

Whatever notion of "full-stack" you have right now, you have no idea how big the stack really is until you try to own it and make things on your own.

Also, and this is a big one, to be a truly great developer, you need to transcend "developer" and understand and master the context in which "developer" exists. Let's call that "growing your stack". You will be a much more insightful developer when you see all the moving parts, of which development is just one.


A grumpy colleague teaching me the ins and out of defensive programming. Then books, code complete is ten year experience condensed on paper.


This was what I was going to say but I figured it was a pretty common sentiment :) The thing that really gave me confidence was finding someone who was willing to take me on and mentor me when I was figuring things out, it makes a massive difference really quickly.


I don't have a CS degree either and wouldn't consider myself a guru or anything, but the stuff that helped me out the most was probably doing daily programmer challenges[0]. Even the ones that seem easy on the surface generally have a few gotchas and they try to explore common CS stuff. It's cool because most of the challenges are pretty fun and interesting, you get to try something new with a little guidance, and you can check out how other people solve the same thing.

0: https://www.reddit.com/r/dailyprogrammer/


What did it for me was doing deep dives into some 'hard' areas: wrote a parser and interpreter for a BASIC dialect in C, implemented 3d software rendering in 4k of Java, wrote some multithreaded client servers in C and Java, did some homebrew gameboy/gameboy color dev in z80 assembler.

Workign through things like this really gives you a lot of confidence. There are a lot of resources online for this stuff nowadays. If there's something you read about that makes you go 'wow, that's impressive', define a manageable subset of the subject, and go do it!


Having something that I wanted to build/hack on was what helped me get started. Most people starting out focus solely on doing tutorials, but it's really hard to get things to stick for me in that scenario. Having my own project allowed for me to trouble shoot, build, and deploy my own app helped me stay motivated to learn and gave me great experience.

At the beginning, I wanted to hack on simple things like creating a blog or twitter clone which pieces of can be found in tutorials. As you get more experience you can build increasingly complex things in shorter time spans.


"As iron sharpens iron, so one person sharpens another." I think the best answer to this question is to work with talented people. I've had a many working relationships with others who were incredibly sharp, which has enabled me to expand my knowledge and fill in gaps. The tricky part is finding and getting into roles where this can happen. I suppose I've been lucky in this regard. I think being honest about who you are, and showing people that you're always learning (as, clearly, you are), will go a long way to opening doors like that.


Peter Norvig agrees with you in "Teach Yourself Programming in Ten Years":

http://norvig.com/21-days.html

Work on a project where you are the best programmer; work on a project where you are the worst programmer.

Peter also stresses "deliberate practice," a point I did not appreciate until I read the book "Peak" recently.

https://www.amazon.com/Peak-Secrets-New-Science-Expertise-eb...


I've found great personal growth when I move beyond my comfort zone and operate in an anxiety-invoking, hellish space of uncertainty and fear of failure. The "process" is far more important to my personal development than the ultimate outcome. So, I grow personally regardless of whether I fail.

With this given, I recommend you give yourself permission to fail, so that you may grow, and take on a stretch goal. I've done this a number of times. I'd gladly share more with you if it were of interest. See my HN profile to contact privately.


I would say a mixture of two things:

In a more general view, having skilled peer developers that have extensive knowledge in the field I am working on and are willing to mentor. I did my BS in a dual system that consisted of half a semester studying and the other half working in different teams of a software company with ~150 devs. During this time I had two or three very good mentors who not only made sure I am doing the right thing but also showed me how to do them correctly. This meant mainly reviewing the architecture and code I came up with and telling me when I was doing bad practice and how I should do properly. I think the situations I learned most in my whole studies were when one of these mentors refused a review or help me some higher level problems until the flaws they found in my code weren't fixed. This made me develop a feeling about if the approach I'm taking might be a bad idea and what to do instead that I can most often trust to a certain degree.

The other thing is to go beyond the basic tutorial steps for advanced technology like datastores, queueing systems and such. To me, this works best when I have the option for using them for a certain case that is (or will be) more or less important for production. I think gaining brief information about different frameworks etc. without wasting too much time before you need them is very important to know your options but you only fully understand the characteristics and problems behind them once you put them to an extensive and got hit by their pitfalls.


Becoming responsible for the technical lead of a number of teams. I was always strong in solving things whilst implementing. Doing and thinking interchangeably. Getting to the root or final design in an iterative fashion. However, that doesn't really scale. So now as an architect I have to come up with a design or analysis without coding it out first. That requires a different set of skills.

Second, it helped me grow from always late to (mostly) always early. No help in sharing a design after the feature implementation is already started. It's either time lost on whatever was done already, or time lost discussing how to adapt it so it fits. You should discuss before you start, so as an architect that makes you responsible to prepare before that moment and facilitate. Be sure to discuss designs with your team(s) though, don't go all ivory tower on them.

Third, it forced me to grow in the social aspect. I am only as helpful as the information I can bring to the engineers in my team(s). I learned I have to understand the individual engineers, how they work, their strengths and weaknesses, their preferences. I learned that showing genuine interest in them and their wellbeing is a great way to achieve this. I have never feared the coffee corner or desk/room/lunch talks so it was mostly paying some additional attention to their responses, talks, interests, etc. I daily use this information to select the right person for the job, adjust my explanation to fit their needs, learn who likes more intervention and who I should (and could) simply trust and run free.


Going freelance. I went from having worked with Java, C++ and PHP to a variety of languages, platforms, business situations and teams. I learned so much about JavaScript alone during this period that I wrote a book about it.

Frequent, real business and engineering challenges. Exposure to a variety of people in organisations from the Netherlands to Silicon Valley, at startups and multinational corporations.

There is no substitute for this kind of learning, and I am so thankful I was able to do it.


My first job on a project that was already up and humming. Before that, everything I had done was in isolation, and typically started from scratch with very little guidance. Sitting down and actually getting to touch code written by skilled developers gave me the chance to see good code, bad code, and design patterns working together in an extremely tangible context. Also, huge confidence boost the first time you ship production code.


I can't help but feel you are asking for a result and everyone is describing a process - which is fine and is very likely to lead to the result, but if the issue you are facing is not knowing when to stop a particular process, then the advice here isn't going to help much either.

Do you mind sharing what is the result you are after?

Edit: I don't mean you will completely stop a process, but rather some kind of checkpoint to measure your progress.


> I don't have the confidence to call myself a developer.

Start building things. Pick some open source projects you like, dig into the code, and try make a better version of them. Also stalk (or if you like, talk to) the creators on Twitter to learn how they think.

Do this consistently and in a few months you'll begin to be embarrassed by how bad and inefficient your previous projects/processes were.

That's when you'll know that you're growing.


I think the best way to grow, or mature, is to make mistakes. And the best way to make mistakes, is to do what we don't normally do.

In a professional setting, this would equate to a job that allows a certain amount of variety. If you can't, in your current role, you should move!

It doesn't matter what the variety is. If your given variety you will grow. Different variety, different direction - but nevertheless, grow.


If you can get a job at a software consulting firm or agency as some call them, you will learn more than in a specialized role at most other companies. You will be forced to complete projects from start to finish in a variety of technologies, and also gain experience planning and estimating. The consulting industry can be a bit degrading, but you will learn faster there than in most jobs.


Spending less time coding, and more time working on skills that have exponential effects on my ability to code and learn.

If you're curious, I wrote quite a bit[1] on this topic.

[1]: https://nickjanetakis.com/blog/have-you-hit-the-point-of-dim...


Nothing grew me the most than (sadly) moving from company to company. I grew so much by seeing how different companies and teams did something, taking the good, internalizing the bad, and then repeating at other companies.

I highly recommend consulting early on in your career to do that. It can be stressful but once you're used to it you will lose the fear of the unknown eventually.


Being out of a job for some period of time after the financial crash of 2007-2008 (I was laid off in '08). I was w/o a job for nearly 2 years which helped me reinvent myself as a web & mobile developer, self taught of course. I was a market risk associate with Merrill Lynch at the time and before that, I had been a software engineer for 7 years.


I think the most interesting thing in these responses is how DIFFERENT they are in spite of a few common themes. Its pretty clear that there is NO one magic prescription for the OP.

If anything, the take away is that your "break" could come from almost anything including random chance, or being thrown into a situation for which one is utterly under-prepared.


I became a much, much better developer when I stopped thinking that computers mattered all that much compared to people. Compared to my co-workers, compared to my users. Computers are only a way to solve a problem, they have no intrinsic value or worth. But people do.

Building human-first systems is the only way to go. (It informs stuff like project management, too.)


Being given a problem where I owned creating a major component for an app, and allowed to create an imperfect implementation. The subsequent briefing on the problems of my implementation was enlightening, and something I dwelt on for a while to try to figure out how to avoid the pitfalls I ran into for the future.


last year I made a resolution to do daily code sketches for fun:

https://www.instagram.com/zach.lieberman/

I have learned a great deal from the act of daily coding and treating code like a creative medium without any pressure on what I make or why. I found myself tackling hard challenges so I wouldn't get bored and learning a variety of new tricks to help make the sketching easier. I wrote about the process here:

https://medium.com/@zachlieberman/daily-sketches-2016-28586d...

I think daily activities are the best for growing -- short, concentrated, and limited in scope and can fit with the rest of your life.


There is no finish line that you need to reach to call yourself a developer. You already are a developer. As far as learning is concerned, I would suggest to learn the fundamentals of computing and you will find every new shiny tech that people talk about is just those fundamentals with a new name.


Public Speaking. Being able to speak confidently in front of people, whether in meetings, in groups, or at conferences as a speaker has done more for me as an individual than anything else. It's a skill that I carry with me everywhere I go, regardless of the industry I'm in. It's something I use everyday.

I know this isn't something specific to programming, but it's the one skill I can point to and say "this is something that has helped me every day." Being able to clearly and confidently articulate my position. Being able to put myself up in front of people and share ideas and potentially be wrong. Being confident enough to ask for help.

I'm never going to learn everything, but this one skill is something I feel is invaluable whatever career you choose.


Being around people who know things I don't.

My first job I was the only developer (until I got to hire a junior), and learned a lot by trial and error.

But I quickly made a massive leap forward when I moved to a team of a dozen developers, all of whom had knowledge, skills, experiences or ideas I could learn from.


Look for weaknesses you have as "a developer" (or whatever you want to be). Focus on them. Work at them until you get better, or at least more comfortable. Find new "muscles", skills, what have you and push them. It's a lot like music.

Specifically for me, it's been reading. I used to not like reading source code. I often wouldn't know what I was looking at. If I found the style strange, I wouldn't know if it was inherent to the language, the project, or just the developer. Just knowing library X can do T doesn't always answer the question; sometimes you have to know exactly how it does T, with what tradeoffs &c. Same goes for APIs. Reading has brought me more learning than anything.


1. Do something - especially if it is an idea that contain things that You don't know at the moment - by trial and error You will learn things.

2. Find a mentor - this is the fastest way to improve. I have 5+ years of experience in frontend development - lately I've learnt a friend how to work in the frontend development and after one year he know almost everything that I do (I don't want to talk here about dealing with specific quirks and/or development problem solutions by programming because it is something that You'll eventually achieve with time) but yea, I was learning by trial and error and he wasn't wasting so much time like me because I've told him everything before he even tried.


A great mentor that challenged all of my assumptions, taught me how to communicate (always ask _good_ quesions), taught me how to design code (pseudo coding is still an excellent design tool), and taught me how to complete projects.

That and just having a passion for writing code.


For me, it was realizing that I wasn't any better or worse than the other people on the team, and that my opinion was just as valuable when discounted by my experience level.

Before that, I was always reluctant to speak up, or express any strong opinions, because I was always surrounded by people who appeared to have their shit together and were very confident and forceful about expressing their opinions. I've probably overcompensated since, but finally allowing myself to feel that freedom to just say, "No, I think that's not the right way, we should try this instead," has allowed me to progress much farther than any technical achievement I could name.


> what one thing let you grow/learn the most as a developer?

Responsibility, there's nothing quite like it. Responsibility for code being shipped to production, responsibility for a terrible bug you shipped, responsibility for completing a new feature.


Fail early, fail often. Try lots of new projects outside your "skills". See what interests you, and where you want to go.

We learn by trial and error. But I think you already know that. I think what you need (to paraphrase the Wizard of Oz)... is a piece of paper that says you are a developer.

You know how you get that? You write it on your resume. That's it.

To be a developer, you call yourself one. Period.

To be a good developer, and one that people want to hire, you have to to have the experience. And it sounds like you have that. Different from mine, different from other peoples... but you have it. Look for new positions that need your skills. It's a great way to grow.


Learn to love the language you feel most comfortable with and develop some great things with it. Become excellent with the language you love.

I love PHP. I think it is underrated and most people and companies prefer Ruby or Python. Those are great languages.. but PHP can do just as much. So I know some Python.. I could probably switch and write code in it, but I just prefer to code in PHP. As for Ruby, I longed to learn it, spent some time understanding it and while it is okay, my preference just returns back to PHP.

Sure, it is best to learn the languages in demand, but I'm strong and proficient in PHP. Why not stick with what I love?


I have a CS Degree; my most growth as a programmer was when I got a job at a business to business consulting firm. Putting a lot of the theory into practice in a professional setting was a trial by fire, so to speak.

In my version of the world; most people tend to specialize and know their area very well; but often do not know the breadth of technology very well.

If it is an option; you can try to go back to school for a programming degree. Or you could go to a conference for something different than your day to day job. Or you could work on an open source project using different technologies than the one you work on in your day job.


There is no precise recipe, actually. You will find your own way.. For me a turning point was the moment I start interact with a team. Developing things together with others forced my brain to think how to make things clear not only to myself.. also, discussions with coworkers make you open mind to receive critics, to learn new strategies. Look at agile development process .. A lot of people criticize it, but the merit of it is that people are pushed to talk to each other and to share responsibilities. I would only consider someone a developer If he/she knows to play within a team.

May the force be with you. ;)


Doing new things with guidance and a safety net. Working solo you can push yourself to do new things but it's hard to tell how you might do them better. And some things I'll pay someone to do for me rather than try to do myself because I'm afraid of the consequences of failing (for instance, hardening a server).

But doing something new under the instruction of someone who knows it well, you can ask WHY they do things a certain way, or what would happen if you did X differently, or even just "help, it's not working at all!" and learn a ton from the answers.


I'm a product manager, not a developer. I spend ~10% of my time building little tools to help me do my job - not nearly enough to be proficient in any one area.

So access to 'good' GitHub repos has been a godsend.


For developing skills, a simple answer is learn a new language. Do a personal project in something dynamic and object oriented (e.g. not C). C is a great language and you will be happy you know it. But learning new languages forces you to think differently which allows you to think differently in the languages you already know.

Also knowing how to build web connected GUI apps in an afternoon is also a very liberating skill for a developer (Python, Ruby, Clojure are all good choices; or C#, Java if you wanna stick somewhat closer to what you know).


If you're holding your own as a CV developer in embedded systems, call yourself a developer; you've earned it!

(Fellow Mech E degree holder here, but I've never worked a day outside of computing...)


I don't know if you can phrase it like this. If there was such an answer to your question you'd know that before you'd know how to write a single line of C. There are many fragmented things each with its own quickly diminishing returns and constituting nowhere near a significant portion of the whole.

Other than that, just experimenting with a project that starts out simple, following through with where it leads you not giving up and seeing how deep the rabbit hole goes has been instrumental in my experience.


If I may say two things:

Firebug, and a copy of Javascript: The Good Parts from the library.

These two things put together helped me finally grok functional programming, and really understand what was happening in my code.


Seeking out professional and technical mentors. The amazing thing to me was just how willing skilled engineers were to lending time and effort to me simply by virtue of me asking.


>The amazing thing to me was just how willing skilled engineers were to lending time and effort to me simply by virtue of me asking.

You were flattering them I an extremely sincere way. So if they help you they can be altruistic, be flattered and call that work.


(1) Not just looking at a library function of a well known library but digging in to read the code and understand how they were architecting software.

(2) Whenever I ran into some kind of bug/anomaly I would refuse to hack my way around it. Sometimes I would soend days getting to the bottom of something. Usually I was making wrong assumptions and this has helped calibrate my intuition and gives me a better sense of what ought to be going on under the hood.


Having a better understanding of the importance of naming things.

    thing.prepare_frobnicator()
    thing.ensure_frobnication_ready()
    thing.frobnicate()


Here are a couple of things that I have learned at my current employer. Throwaway because I'm stuck here for another six months.

Development time matters, maintenance does not.

You can win an award for a program with 500 line functions that is vulnerable to SQL injection.

Copy and paste is a lifestyle.

Static analysis, unit tests, and repeatable builds are crazy talk. You will be treated as a pariah if you bring any of these topics up.

Version control is too complicated.

Catching all exceptions fixes bugs.


(Stuck writing a very limited subset of C i.e. no malloc(), free(), libraries etc etc)

I'd start to find out why this is at your workplace. You're sure to learn something, either technical, in social skills, or with what not to do when negotiating a bureaucracy.

Hint: A good way to get most programmers to spend a lot of time explaining what they've done is to stroke their ego.


Given that it's an embedded system, the product probably has realtime or reliability requirements that are incompatible with those things.


The opportunity to prototype projects and explore technologies without being under constant observation by co-workers and supervisors.


Letting go of the notion that you aren't a developer. You are a developer, you're just self-taught. There's not a "right" language or project. Pick something that inspires you, pick a language you want to learn, and start hacking away. It will help you build your confidence and provide an outlet for showing your enthusiasm to others.


Time. As long as you're practicing your skills by writing code and learning the theory, you will improve as a better developer.


I did study Electronic Engineering at university, but I have developed my skills as developer by learning languages by practice


For me, it's having a great team. Working with like-minded individuals and being able to bounce ideas off them, and reviewing each other's code is a great way to boost my effectiveness. It keeps me focused and gives me confidence -- both that my ideas are sound and that my implementation is relatively quirk-free.


Understand that trust of my managers is the most important tool you can have as a developer.

Without that trust you are just a coder.

The trust is necessary to be able to push your projects, extend deadlines and have a general influence on the shape and quality of the product.

Architecting the product is much more valuable experience than writing code from specification.


Coding from scratch, making mistakes, fixing them and only later looking at proper well engineered solutions.

Example: write your own CMS, then look at WP, Drupal, Joomla. Write your own web framework, then look at Struts or Rails.

Then what you end up using is not magic but shortcuts that you can understand and sometimes improve upon.


Reimplement something you've already written in a different language. The syntax and ecosystem knowledge seeps in quicker when you already know what you want to write.

Knowing multiple languages can let you get a wider range of gigs and help out when making decisions on what tools to use for new projects.


Learning not to look down on any technology. Anytime I read technology X sucks (C++ sucks! PHP sucks! Relational databases suck! JavaScript sucks! Python sucks! Java sucks! C sucks! Linux sucks! Windows sucks! etc. ad naseum) I know that I'm dealing with an immature developer.


Throwing myself fulltime into building a product. That particular venture didn't work out in a business sense but oh my, having to build everything on my own with no help made me level up so incredibly quickly, and exposed me to problems I didn't know even existed.


Writing a big system, and failing miserably.

I knew all about "second system syndrome", but I still did it. The new system would be more general, more configurable, more efficient, use exciting dynamically created code... It was a disaster. Now I know not to do it again!


Mentors.

I learned a lot from HN, much more from side projects. But a mentor helped me clear the chasm between "writing code" and being a software developer.

Honorable mention goes to quitting my job (with savings) to start doing development and data science consulting full-time.


Taking over someones projects; one massive distributed monitoring platform, and one CMDB.

I'm self-taught and the person who created those projects was likely educated. So taking over their code was a massive and instant dose of knowledge to me.


Coding and architecture systems. And constantly asking: - How can I write this in the simplest way but not in a simplistic way? - How could I have built this in a simpler way with less things that can go wrong?


Google Search.

Ability to search other people solution, to read how they approach the problem, what solution is good and why is really invaluable. Also it saves alot of time, because usually google shows very relevant result.


If you're looking for a single, extremely practical thing, I read the book "Design Patterns" by Gamma, Helm, Johnson, and Vlissides. The patterns in the book were somewhat helpful, but starting to think in terms of patterns really did help. Years later, I rarely think in terms of specific statements or calls needed, but in terms of higher level patterns that I can combine. Things like "Hmm.. this situation really calls for a level of reliability and error recovery which normal REST APIs won't provide, so let's combine 'idempotent calls', 'event queues with guaranteed delivery', and 'synchronous wrapper for asynchronous calls' to build a solution."


The lead guy leaving and me taking over his responsibilities and role.


Working with other developers, in person. I worked remotely for years. I moved to a new city and I learned so much when I started working on a team, in person, and with other people.


Learning Forth.

(cf. http://thinking-forth.sourceforge.net/tf-kindle.pdf et. al.)


you just asking about one thing, in my experience there are many different factors that contribute to become a good developer, but if I had to choose one would be "challenge yourself".

No matter the task or how hard it is, you can do it. Think about it and let it settle in your mind, YOU CAN DO IT.

When you face IT projects and challenges with that set of mind every thing else just falls in place, the only thing you need is challenging projects, find those either at work or outside of it.

Best of luck.


People are getting downvoted here for legit answers; so weird.

I'm still going to throw in: spending all day reading Hacker News. just kidding!

HN noprocrast has been more helpful than that.


Practice, Practice, Practice.

To many folks call themselves developers because they can write code. The old saying: "Jack of all trades, master on none".


Experience. Nothing beats it.

Also being forced to understand a large codebase, and from that understanding why the 'best practices' were put into place.


Working with other great developers, designers will give you superpowers. Find someone you like, seek them out and try doing a project with them.


Working with knowledgeable, patient, and helpful developers who had experience with a wide range of technologies, processes, and coding styles.


learning FRP (in my case forcing myself to rewrite an app I had made using bacon.js) dramatically leveled up my programming and the way i think about programming.

i can't possibly overstate the paradigm shift in my thinking afterwards. (not clear if that just speaks to the degree that i was misguided)

a more recent development was forcing myself to rebuild my shopify store using webpack/ES6


Writing code. Then reading that code, working with it and starting over and writing it again with what you learned.


Close working relationship with my customers without business management or 'transformation' sitting between us. Shortened the timelines, increased velocity and trust with business partners. Business loved it to as they began to understand more deeply the art of the possible, time to value became completely transparent and we could prototype, iterate, enhance and productionise incredibly quickly


Unquestionably it was working with other talented people. All else pales into insignificance by comparison.


Don't be afraid to make mistakes, learn from them, and learn to recognize where you've made them.


Learning how to learn, and also how to practice.

"Master Practice in order to create Mastery through practice"


Agree with untog; freedom is hugest and I'd add having a decent risk tolerence. But since value is also important I'd say my knowledge of economics helped me grow the most; especially relative to other developers. My instincts honed from that allow me to very easily tell fads from real solutions and plan for long term team development.


one piece of advice that stuck onto me till date: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

Write/Re-write/optimize is a good cycle to be in.


Ask for help when you need it


Completing and releasing a project thats larger than all my previous projects.


What did I do? Interdisciplinary projects. More specifically, building things which must work in the ocean and be operated on boats by salty old fishermen who aren't willing to put up with anything fiddly.

What did I learn? First, to resist giving up in the face of fears over lack of skills/experience/knowledge or lack of ability to acquire skills/knowledge. Then, to ignore it altogether. Finally, to turn that would-be fear into a motivating force which helps me to focus in on achieving my goals.

How'd I get into all that?

As a second year CompSci undergrad I took a freshman Intro to Ocean Engineering course to fulfill an engineering elective requirement. In spite it being a freshman course, there was a rather lengthy team project. The goal of the project that semester was to build a device which could be dragged along the seafloor by a boat, and which would detect pockets of water with lower salinity (salt content).

My role on the team was to build the sensor package for the vehicle. With ample help from an excellent professor who specialized in water wave theory and insanely low-cost in-situ sensor development (shoutout to Dr. Eric Thosteson) I managed to cobble together a CTD (conductivity, temperature, depth sensor). I'm in my 30s now, and I still remember all the little details of that project to this day. It used a PIC16 microcontroller, a simple pre-calibrated 5V linear analog temp sensor (0.1V = 1°C), a $15 motorola linear analog differential pressure sensor (one side reads pressure within the sealed box, the other side I filled with glycerin and capped with a semi-permeable membrane and reads the pressure of the seawater), and a 'homebrew' conductivity sensor made from a comparator-based relaxation oscillator, where two titanium wires exposed to the seawater serve as the measurement cell, acting as the resistor in the oscillator circuit. The oscillation was balanced around ground so that current flow would reverse with each cycle, minimizing the impact of electroplating on the probe. The sensor package communicated via a tether wire back to a computer on the boat via balanced RS-485. Before starting this project I never knew that these things existed. The idea that I could now write code which executed on a single chip which I could then build into a circuit which does actual things in the real physical world, and that I now had the skills to do this all on my own was crazy exciting to me.

The project made me consider a variety of crazy things and learn a bunch of new skills (drilling acrylic for sealed cable glands is a huge pain). However, I think it made me realize one very important thing: that fear I had over not being an expert already and the worry about not being able to grasp new skills were completely useless.

After the project I did what I could to stick with Eric, the professor who helped me out on that crazy project, and worked as an engineering assistant on any projects he or his grad students had for me. The fact that I could write good code was a huge asset, as most students in the field are already learning so many other crazy things that they can't devote the focus/attention required on learning strong software engineering skills. After doing some grant work for a nonprofit oceanographic research institution, he was asked to come on as a full time employee. Since I'd been assisting with that work, I managed to come along for the ride. The pay was pretty bad, but the experience was priceless. I could easily fill a book with the lessons it taught me. But really, it all just served to reinforce that one big lesson I learnt back on that undergrad project.


Learning F#, hands down.


throwing out old code and re-writing from scratch, every version gets better. obviously this is mostly for my own projects as this would not be acceptable at most companies


Code Reviews. Doing them as well as getting your code reviewed.


This. For me, I loved working with a specific team because their code reviews were detailed and extensive - it really elevated my skill with the languages and technologies. It also made me realise apathy and yes-man-ism are far worse for careers and products than (constructive) criticism. I'll take a brutal code review over a lazy one any day.

Having said that, code reviews are also an acid test if you can communicate well. They're more intense than most interactions, and much easier to screw up. Second opinions/having a mentor review the code review if you're completely new to it is recommended and might save one or more relationships.


My hair and my beard


Realizing that there is no 'one thing'.


When I don't take myself too serious

I am a serious developer


The key: AKL. Always Keep Learning.


Learning a functional language.


READ -> WRITE -> REPEAT

Reading code is quite different from reading text be it fiction, non-fiction, poetry or prose. One striking difference is code is not optimized for (human) reading whereas books are (at least the good ones). So trying to make meaning of code requires a true companion to reading (and comprehension) - imagination. I found it immensely changes the speed at which I could absorb content when I could build a mental roadmap and try fit things in. So if I was reading code that dealt with a new domain like MRI/PET scan imaging software, I started with domain knowledge first and then followed the code to draw parallels. That helped me build a mental model of how the code modelled the problem domain(e.g. window width/level, reconstruction) to familiar software domain (pixel values, approximations). Now once I had these 2 mental models and how they are connected. I would try and implement them in small independent ways and then combine them (the unix way if you will). Once I had a decent grasp on these two models (i.e. I could explain the domain concept to at least 2 people - one who knows it already and one who does not and visualizing the program execution in my mind) I then slowly added more details to my mental model.

This however, was different than the first step. Now when I read more concepts, I first try to fit it in the mental model that I have, imagine how I would implement it and then actually see an implementation of how it was done by someone else. Usually I come up with better solutions but thats because I am ignoring some constraints that the developer(s) had.

So after a few iterations, you'll subconsciously built great organized mass of knowledge that you can add to or draw from. This one slow, hard exercise had improved me as a developer more than learning any new framework or language. These days I am not the first to jump on to the next shiny thing but once I do decide to my progress is way faster than what I had before and as compared to others giving them the impression that I am a fast learner (which surely I am not).

So a satrical way of stating this is to be a better developer, just write more code, which although partly true does not make sense unless you realize that your primary asset is the mental models you have built over many many hours and years.

What i struggle with most is to keep up with the rate of new information available and the consequent higher demands of filtering it out and the physical limitation of my memory (I cant remember every detail of everything I have learnt) and these models are complex enough that I must spend time to write notes in a way that they are optimized for fast reading without losing too much detail.

So yeah, off topic but that one thing sure did make me a better developer (in my opinion).


Curiosity to learn new things.


Big, multi-year side projects.


making mistakes and learning from them as one Amazon engineer found recently


It was this one internship that I had where there was no formal process or program to guide me. At the time, it seemed like it was going to be a nightmare, I certainly imagined early on returning to my classmates with stories of disappointment, as there was almost no supervision, and everyone I worked with was way too busy to try to think of fun little toy projects for me to work on. I remember thinking it just didn't really seem like the program was very much of a "thing", however I ended up being very wrong and this one internship I'd consider to be the single most important experience for me as a developer.

In 2012 I got my first internship at Intel to work on post-Si validation for atom. I remember there being a huge amount of build up in my mind leading up to orientation, "What should I wear? Should I look up how to act?" etc... On orientation day, after all the usual cheerleading, all the other interns waited in a room for our managers to come pick us up and give us a tour. It felt like we were waiting to get new families. I saw each intern get picked up by smiling, charismatic managers, all happy to see them, one by one. My manager never came as he was too busy and I was told to just come back in the morning and I'd get a tour.

So the next day, I did, and our meeting seemed forced and hard for him, but he was really trying to make my internship seem like a "thing". Then all the interns who were in my section were given a tour of the lab and shown basically what they were working on, the different projects going at at the time. I remember being very concerned about what I was going to work on, what I was going to "be" so to speak, eagerly listening to every word, hoping to catch anything that would impress my superiors. Then there was one thing that caught my eye, a robotic arm, barely draped in a cloth, that just looked neglected.

After the lab tour and lunch, I met my mentor, a lead on the team, and we (me and two other interns) were to be assigned our work for the summer. This, it felt, was the moment I had been stressing over. They were each given duties, but when it came to me it felt like my mentor didn't really have anything in mind yet and so something inside of me just blurted out that I wanted to work on that robot that I saw in the lab. He told me a story about how it got to be that way and how no one was really in charge of it and that for now I could start just by figuring out how it worked and could take it from there.

I ended working there with almost complete ownership of my own project, just straight up coding non-stop, for what started out as the summer but then extended into a co-op that lasted until I graduated. Having something to work on, with very little structure, every day, was so much fun you wouldn't believe, and it was there that I developed the foundation for all of my programming skills.

I took that project from one machine that turned on but didn't do anything to two machines that could calibrate themselves, move through an arbitrary topology using pathfinding, pick up parts, take pictures of the different serial numbers and identify them in a database, and cycle through the remaining parts in the tray with very high accuracy. Each component in this ecosystem was networked so there had to be fail safes, like you don't try to move to the motherboard socket, if the actuator is already down, etc... and there were a lot of components. The only thing missing from this that would have made it a complete continuous integration system for Silicon was a test runner, which I would have had no idea what to do for back then. Any way, although I was a software intern, I even got to build a safety cage with an interlock, complete with a hardware-based fail-safe switch, for the robots, out of extruded aluminum! To be honest I didn't really know what I was doing the whole time, which is why it took me over a year to do this, but it was such an incredible learning experience that I will cherish it forever.

My manager, team, and everyone at Intel ended up being really awesome to work for and the internship was awesome, even if it wasn't a "thing", but hands down the best part of that experience was just figuring out what to do with myself and then becoming deeply and passionately absorbed by it and coding nonstop.


Solving actual problems.


Public speaking


Mentorship


Working at places that hire really good developers (not trying to be immodest).

I languished in one place for many years and when I left, I learned a whole lot in just a couple short months. There's a difference between "knowing of" a practice and working among a team that lives and breathes a set of practices every day.


1) Reading and getting to compile/work other people's open source.

This more than anything will introduce you to the various styles of 'pro code' that people use, at least in terms of formatting. And if you can pick out the good one's you'll see how a pro project is organized.

2) Learning more than one language

3) Cloud


Biggest things I have let grow...

My raspberry bush is the biggest thing I've ever let grow.

Inside the house would be my gorgeous aloe vera pla y


Having a hobby that involves developing in lots of different languages and techniques.


finish an app, write another. rinse and repeat.

gamedev helps with that because it's much easier to call it a day and start another game.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: