Ask HN: What has improved You as a Developer?

54 points by xupybd ↗ HN
What investments have you made in yourself as a developer that have really paid off?

I've found high level books written by experienced developers have really helped me. In the past I'd try to learn this or that shiny new thing but found little long term gain.

What's been your long term successes?

64 comments

[ 4.5 ms ] story [ 174 ms ] thread
Improving communication skills and listening to customers. I see my goal as a developer to deliver business value, not to try to write perfect code. One has to balance delivering value on time with code quality, but too often I see developers focusing on technical skills as if code had a value in itself.
I'm experiencing something similar. I'm having to learn to understand why the customer wants something and avoid just giving them what they want. Often what they want is not the simplest solution to the problem the want to solve. Sometimes you almost need to understand their operation as well as they do just to ensure you're delivering business value and not just adding features and complexity that will eventually choke the ability to change.
Exactly. That’s a skill that in the long run has more value than learning another programming language. I freelance so I have a big interest in establishing long-term relationships and getting referrals. You get that from trust and understanding the customer’s business requirements.

No business ever has the requirement “We need 2,000 more lines of Javascript by next month” but you wouldn’t know that just listening to programmers.

what are you programming in?
I freelance taking over failing and failed projects, rarely do new development, so I’m programming in whatever my customers have. PHP, JavaScript, MySQL, Python, sometimes Ruby or C#. I also do lots of Linux system admin.
1. Writing original code. In the world of JavaScript this is both discouraged and extraordinarily feared. Do it anyway.

2. Avoiding OOP and composition early in my career. When you learn to focus first upon the goals of an application how things come together becomes a late triviality not worth serious consideration.

3. Know the foundations, standards, and intentions of your software environment. Hoping to bullshit your way past this with a tool is an artificial constraint that slows down delivery, limits creativity/capabilities, and severely retards performance.

Number 1 resonates. Front end is frameworks come with more required learning than the work required to avoid them. However they promise to work for all your problems so you can standardize your teams and projects. Only they churn so fast they're out of date after your first serious project.

I'm not sure I understand number 2. I'd love to hear more.

Early in my career when I was learning to program I was discouraged by reading OOP code. I found it hard to follow. Deciphering the value of this by just reading the code felt like trying to translate some lost ancient language from stone tablets. The more I put off learning OOP the more it felt like unnecessary decoration.

Here is an example of a real world utility item with lots of decoration: https://c2.staticflickr.com/4/3098/3142471026_1c8f659c46_b.j...

I would rather do other things then spend the time digging through decoration when debugging.

4. A fourth item I should have mentioned above is avoiding long builds. Early in my career as a JavaScript developer the front end space was seen as a toy where you send the children to play. All the serious work occurred in some bloated server side Java application. The Java developers never seemed to get anything done as they were frequently waiting on builds that could last more than an hour. When this madness later crept into JavaScript via gulp, grunt, webpack I avoided it. I could not see the value in slowing down my speed of iteration. As a result my code was dramatically smaller. It contained less unnecessary bullshit. Now I have a 5 to 10 second build in my applications due to TypeScript, which does slow me down a little but it allows me to plan and scale the features of my application so much faster that it’s still a strong added value.

"When this madness later crept into JavaScript via gulp, grunt, webpack"

finally somebody said it

not the OP, but I'll propose that the code inside methods is largely procedural code, and this is one level (what you need to learn first), and then how it's organized is a whole other world subject to much debate. (even given SOLID DRY OOP etc.)
Big fan of the first point. I pretty much try my hardest not to put third party libraries for tiny features. Obviously there's gotta be a balance but I don't see a point in introducing massive bloated libraries for small features.
Understanding the people around you - be it more junior engineers, managers, PMs or other people. They all have motivations and skill sets that are necessary for the big picture.

You get more effective by understanding their needs and why they are asking you for something.

Taking risks and switching jobs. This has exposed me to new ways of thinking and the ability to compare and contrast the different solutions I have seen in my previous experiences.

In a sense , when to move to a new position you have to prove yourself again, and it also keeps you from becoming complacent .

Mentors and colleagues that are smarter than you, have higher standards than you or both. When working closely with people who can push and challenge me I learn mode and evolve faster.
Be technically fearless. Have the attitude that there isn't anything I can't build. If I'm not familiar with the topic, I'll learn it. And deliver. This confidence comes from experience, and a strong understanding of fundamentals.

The above provides technical credibility, which is immensely helpful for organizational politics. People listen, and respect your opinion if you're capable and deliver. Learning how to communicate, lead, and navigate people is much easier once you're technically credible in this field.

I didn’t learn this until I officially worked for a year.
Books, articles, podcasts and interviews have all helped me improve my general knowledge of the technology world.

However, the only thing that has helped me improve my raw programming ability is reading and writing code. Especially when working on new or difficult tasks.

Don’t be afraid of writing the wrong code. Just sit down and write it.
Also don’t be afraid to throw it away.

Sunk cost fallacy be damned, you often write the first one to figure how to correctly right the second one.

Yes! I thought it was implied in my comment. Thanks for making it clear
Persistence.

I develop apps for a living and work solo (coding, design everything) and have taken up very large projects. One of the apps I built a few years ago was a full blown YouTube client app with a lot more features. The app is now no defunct because of YouTube not allowing background playback and several API restrictions but that app took me over a year to put together.

Another app was a sudoku app I built which took several iterations to design and built and improve. One of my most recent apps is a Hacker News client which I built the iOS version for about 3 years ago and am just now finishing the Android version of the app. The iOS one took a good 6 months of work to build and the android one has taken me just over 3 months.

I have been able to take over such large projects and crossed the finish line by being persistent. I work solo and from home and basically work every day of the week. Some days it's a lot of hours - 12-16 hours, other days it's maybe just half an hour of fiddling around. As long as I put in at least a few minutes everyday and able to fix a bug or add a small feature or make a small UI design fix, it's a good day. It doesn't have to always be major improvements. It can be as little as adding a new theme color.

I learnt this from my past experience in weight lifting. Being persistent everyday makes you achieve major goals over time. This can be applied in other areas of life too - like reading books, weight loss etc.

There was a recent post on "The unreasonable effectiveness of just showing up everyday":

https://news.ycombinator.com/item?id=27833064

https://typesense.org/blog/the-unreasonable-effectiveness-of...

I think aiming to understand the „how and why“, at least a few levels deeper than directly obvious is what helped me in a debugging and fixing a lot of things. Having a deeper understanding of your tools, your environment and the problem at hand helps me a lot. When a library you use does something unexpected, or is missing documentation, dig in, read that code, debug it. Understand the details of your programming language of choice, not just the basics.

It takes time and requires a certain level of curiosity, but, at least for me, I think it pays off.

Implementing stuff from scratch that I didn't have a full grasp of. I've done this with a SQL engine, a number of compilers and interpreters, two x86 emulators, web servers, JavaScript and CSS frameworks, JSON parsers, and so on. (All of which is publicly available on github.com/eatonphil).

Implementing a thing really gives you a much deeper understanding of the thing (and tangent things) even if you never use your implementation in real life.

Working with other great developers.

Learning to keep it simple & methods for avoiding code duplication. I tend to find when learning a new language that avoiding duplication teaches me how to use the language properly.

And the book, The Pragmatic Programmer helped me to communicate better.

- Writing small, standalone, often throwaway programs to play with a new language feature, concept or API, or to answer a question about how something works or performance. This helps with understanding but also got me over the fear of starting a new project from scratch.

- Learning functional programming (and applying the above to that learning) made me a better programmer in the non functional languages that I still spend most of my time using.

- Reading books and technical articles as an ongoing thing over many years, little bits of knowledge and understanding really accumulate over time.

- I actually found that practicing coding interview style problems and using them as a motivator to better understand core computer science algorithms and data structures has improved my programming, I think for similar reasons as my first point above.

Anytime you’re building a new feature or product, focus first on getting something functioning end to end. From there, start to iterate on the middle piece by piece until the whole thing works the way you want.

Say you’re asked to build checkout flow for your e-commerce product. You need a shopping cart page, a shipping page, a billing page, a confirmation page, and flow out to stripe, and then a success page.

Start by creating a single page that just shows a product name, user name, address, billing address, etc, and then a button to “create”. Click it and it should call off to stripe with that dummy data, and then it display a success alert.

Now circle back and make the address and billing data input fields.

Submit again.

Now circle back and create a couple of dummy pages that you click through with the forms and a pre submit confirmation page.

Now go back and start to wire up a shopping cart page.

Etc, etc.

By creating a through line at the start, you can test everything you’re building end to end, so you can really hone in on the product experience and make sure it’s what it should be for your specific product. It also gives you more flexibility to give demos along the way, as well as release the product earlier in its maturing cycle. Maybe you won’t love the style and format, but it’ll be more than good enough to get into customers hands sooner in the process.

I write down my plan on paper. It's puts me in a methodical state of mind.
Not worrying about the next big technology and building within the constraints you have
First understand the current flow of data, then the MVP end-state flow of data, then the complete desired end-state flow of data. Next take the advice posted by wjossey and implement the most minimal end-to-end MVP that flows that data. Last, iterate until you get to good enough.
- Learning from others around me who are smarter/more experienced. This is maybe the number one thing.

- Switching jobs when things get boring or I feel like I am not growing in the ways that I want to be. It's eye opening to begin a new job and feel like a noob again.

- Building side projects. Reading and following tutorials are good and all, but there comes a point where you just gotta build something to really grow.

- Becoming part of a community, because it motivates me to learn and improve and also to try to share what I learn with others. I think this happens best at a small, local level. I don't get much out of attending the big conferences (other than it's usually fun).

- Having a blog, or just someplace to keep track of the interesting things you learn about. Can be a good marketing tool for yourself as well.

- Keeping a high level of communication going with your colleagues about what you're working on. I feel like this has earned me promotions.

> Switching jobs when things get boring or I feel like I am not growing in the ways that I want to be.

I'm trying to do this, but the only jobs I can get are the ones that will very quickly put me back in that position.

Detailed documentation after finishing... I find bugs and areas for optimisation when I'm forced to articulate decisions behind code months after writing it.
leaving behind the generally toxic startup small business universe for less glamorous government work.
Writing a lot of code, including a lot of bad code. Gaining intuition about what works and what doesn't through experience.

Favoring pragmatism over dogmatism.

Good written communication skills can get you out of a lot of sticky wickets. I took one technical writing course in college, and I probably use those skills the most.
Probs common knowledge, but general data structures and algorithms. Coming into web from design I was blissfully unaware about terminating iterators once their conditions met to avoid CPU cycles.

Also, I love Pluralsight videos to learn, but others prefer books.

I learn a new programming language every 18 months and use it on side projects.

A couple examples:

2003 Smaltalk - made me a better Java programmer and taught me a lot of history

2005 Ruby - Rails experience helped me level up to a FAANG job in 2008