
Ask HN: What's the one thing that let you grow the most as a developer? - main_c
For the last two and a half years I&#x27;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&#x27;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&#x27;d like to ask, what one thing let you grow&#x2F;learn the most as a developer?
======
dep_b
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.

~~~
gregmac
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.

~~~
jjp
> 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.

~~~
ionforce
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.

~~~
KajMagnus
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?

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

------
untog
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.

~~~
tremendo
_> 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).

~~~
untog
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...

------
lojack
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.

~~~
Tasboo
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.

------
smilesnd
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".

~~~
IcePenguino
> 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!

------
muse900
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.

~~~
mattmanser
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.

------
Insanity
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 ;-)

~~~
valbaca
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.

------
marak830
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

~~~
gm-conspiracy
As a chef, how many hours a week do you work?

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

~~~
marak830
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.

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

~~~
marak830
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.

------
cbanek
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)

------
wonderwonder
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.

~~~
imjared
> 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.

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

------
songzme
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.

~~~
xiaoma
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

~~~
songzme
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.

------
nemonemo
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.

~~~
nemonemo
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.

------
wojt_eu
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...](http://www.audible.com/pd/Self-Development/Practicing-Mindfulness-
An-Introduction-to-Meditation-Audiobook/B00DDVQQLA)

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

------
itamarst
"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/](https://codewithoutrules.com/2016/04/27/which-technology/)

* Choosing a side project: [https://codewithoutrules.com/2016/09/09/side-projects/](https://codewithoutrules.com/2016/09/09/side-projects/)

~~~
Joeri
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.

~~~
sn9
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.

------
electrichead
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.

------
dested
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.

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

~~~
dested
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 ;-)

------
rl3
> _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.

------
sebringj
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.

------
rucker
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.

------
seangrogg
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.

~~~
rainhacker
> 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 ?

------
alok-g
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.

~~~
arsalanb
Could you recommend any books that you found particularly useful?

~~~
alok-g
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.

------
Beltiras
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.

~~~
johngalt
Ha love that.

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

~~~
Beltiras
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.

~~~
kelvin0
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.

~~~
Humdeee
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...

~~~
kelvin0
You will enjoy watching this then:
[https://www.youtube.com/watch?v=N9wsjroVlu8](https://www.youtube.com/watch?v=N9wsjroVlu8)

------
creullin
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.

~~~
lpa22
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.

------
amiheines
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.

------
coldcode
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.

~~~
Starwatcher2001
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".

------
edent
> 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.

------
andy_ppp
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.

------
madhadron
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.

------
yyyfahaf
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.

------
mysterydip
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.

------
0xfaded
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.

------
jamesRaybould
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.

------
wccrawford
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.

------
jimmies
>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](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.

------
laurentl
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).

------
ChrisMorrisOrg
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.

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

[https://www.findlectures.com](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.

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

~~~
garysieling
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...](https://www.findlectures.com/articles/2017/01/22/Software-Architecture-
of-FindLectures-com/)

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

~~~
midgetjones
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?

~~~
garysieling
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.

~~~
midgetjones
Interesting. Thank you!

------
thehardsphere
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.

------
wffurr
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/](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.

------
raverbashing
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

------
cosinetau
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.

------
sulam
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.

------
logfromblammo
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.

------
gtycomb
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.

------
mparr4
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.

------
iheart2code
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.

------
yawaramin
Just want to reiterate the comment at
[https://news.ycombinator.com/item?id=13782032](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/](https://www.coursera.org/learn/programming-languages/)

------
angrymouse
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

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

------
apeace
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.

------
inieves
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.

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

~~~
lmitchell
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.

------
taternuts
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/](https://www.reddit.com/r/dailyprogrammer/)

------
marktangotango
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!

------
AustinGrandt
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.

------
TheRealDunkirk
"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.

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

[http://norvig.com/21-days.html](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...](https://www.amazon.com/Peak-Secrets-New-Science-Expertise-
ebook/dp/B011H56MKS/ref=sr_1_1)

------
Dowwie
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.

------
oxygen0211
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.

------
bastijn
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.

------
davedx
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.

------
djfdev
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.

------
thr0waway1239
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.

------
yokisan
> 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.

------
laythea
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.

------
jackcosgrove
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.

------
nickjj
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...](https://nickjanetakis.com/blog/have-you-hit-the-point-of-diminishing-
returns-as-a-developer)

------
Yhippa
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.

------
pbhowmic
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.

------
crispyambulance
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.

------
eropple
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.)

------
Bahamut
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.

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

[https://www.instagram.com/zach.lieberman/](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...](https://medium.com/@zachlieberman/daily-
sketches-2016-28586d8f008e#.ht88r61b9)

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

------
ankurdhama
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.

------
jasonlotito
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.

------
dood
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.

------
arh68
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.

------
lukaszkups
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.

------
ChicagoDave
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.

------
eric_the_read
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.

------
joshstrange
> 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.

------
edburdo
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.

------
mattbgates
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?

------
reboog711
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.

------
tmsldd
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. ;)

------
cauterized
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.

------
mud_dauber
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.

------
SolarNet
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).

------
sokoloff
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...)

------
soheil
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.

------
CalRobert
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.

------
matt_wulfeck
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.

~~~
tormeh
>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.

------
rdlecler1
(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.

------
singingfish
Having a better understanding of the importance of naming things.

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

------
throwaway65221
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.

------
stcredzero
_(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.

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

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

------
nrjames
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.

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

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

------
tremon
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.

------
lmilcin
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.

------
pmontra
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.

------
hl5
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.

------
irrational
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.

------
jboggan
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.

------
CJefferson
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!

------
johnhess
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.

------
INTPenis
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.

------
ChrisCinelli
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?

------
Dolores12
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.

------
mcherm
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."

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

------
cbryan
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.

------
carapace
Learning Forth.

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

------
angelofm
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.

------
j_s
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.

------
jason_slack
Practice, Practice, Practice.

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

------
snovv_crash
Experience. Nothing beats it.

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

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

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

------
disantlor
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

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

------
boardmad
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

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

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

------
yawz
Learning how to learn, and also how to practice.

"Master Practice in order to create Mastery through practice"

------
Subi
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.

------
venkasub
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.

------
metaphorm
Ask for help when you need it

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

------
benjamincburns
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.

------
davidgrenier
Learning F#, hands down.

------
epynonymous
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

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

~~~
guitarbill
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.

------
tixzdk
My hair and my beard

------
beders
Realizing that there is no 'one thing'.

------
djKianoosh
When I don't take myself too serious

I am a serious developer

------
novaleaf
The key: AKL. Always Keep Learning.

------
eweise
Learning a functional language.

------
sh87
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).

------
harshdeep
Curiosity to learn new things.

------
psyc
Big, multi-year side projects.

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

------
asimpletune
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.

------
ianaphysicist
Solving actual problems.

------
mrmrcoleman
Public speaking

------
Sindrome
Mentorship

------
draw_down
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.

------
edblarney
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

------
sauronlord
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

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

------
jlebrech
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.

