Ask HN: What's the one thing that let you grow the most as a developer?
For the last two and a half years I've been developing computer vision algorithms for a proprietary embedded platform in C. Without a proper CS degree (my bachelors and masters were in mechanical engineering), or experience (Stuck writing a very limited subset of C i.e. no malloc(), free(), libraries etc etc), I don't have the confidence to call myself a developer. So I was looking for avenues to maybe improve my skills and knowledge. So in short I'd like to ask, what one thing let you grow/learn the most as a developer?
252 comments
[ 2.8 ms ] story [ 555 ms ] threadNo 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.
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.
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
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.
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)
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.
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.
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.
Start building things. Pick some open source projects you like, dig into the code, and try make a better version of them. Also stalk (or if you like, talk to) the creators on Twitter to learn how they think.
Do this consistently and in a few months you'll begin to be embarrassed by how bad and inefficient your previous projects/processes were.
That's when you'll know that you're growing.
I'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.
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.
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.
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.
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 ;-)
Those who know, do. Those who understand, teach.
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.
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.
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 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 English -- but one thing necessary is an incentive, especially a positive one.
The issue isn't formal education, then, it's breadth of practical knowledge.
The thing that has helped me most, at least in that realm, is getting bored easily. Once I learned a problem space enough to be confident in my skills there I get bored, and move on to something new. Learning something new always involve discomfort and lack of confidence and "I don't know what I'm doing." So to mitigate that, you can try to pick somewhere that is adjacent to your skills.
E.g. maybe you can switch jobs within your company to working on the platform itself, so you learn a new set of tools and problems but still in same programming language. Or find an open source computer vision library and read the code and learn the tool chain, build some toy projects with it. (Contributing without work's permission might violate your intellectual property agreement, depending.)
More expansive thoughts on choosing something to learn:
* Choosing a technology: https://codewithoutrules.com/2016/04/27/which-technology/
* Choosing a side project: https://codewithoutrules.com/2016/09/09/side-projects/
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.
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.
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.
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.
https://www.findlectures.com/articles/2017/01/22/Software-Ar...
I think there is a fair amount of detail there, but if you have questions I'm happy to elaborate :)
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?
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.
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.
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.