Ask HN: What has improved You as a Developer? | Hacker News Reader

Ask HN: What has improved You as a Developer?

54 pointsxupybd62 comments

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?

View on HN

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.

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

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.

YAGNI. Following it strictly, following it mercilessly.

Then follow the other user's answer about getting something working end-to-end first and fleshing it out after that.

These two things alone have helped me prototype things from ideation to working, testable project with almost a 100% success rate (even if the idea ended up being bad, of course).

EDIT: Should expand on the "mercilessly" part. Even if you think you'll need a trivial, small abstraction five minutes from now, don't code it until it's blocking you. It seems extreme (well, it is part of the Extreme Programming principles) but it has granted me a 10x improvement in productivity as well as code quality after really committing to it.

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.

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.

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.

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.

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.

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.

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.

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

1. Find a job on a team with good, experienced people trying to do something hard/ambitious. Learn from the experience.

2. Read other people's code. Reading others' code is a skill. Reading code is the best way to learn what's idiomatic in a language.

3. Focus on principles. Learn how they're applied in different settings. Don't spend time chasing the "new shiny" unless you have a need/reason.

4. Work on your people skills. After a certain point, telling computers how to behave becomes easy. But communicating with and inspiring people, learning how to amplify others' strengths, work around their weaknesses, and doing it all w/ humility and grace, while leaving others feeling positive about the interactions can be challenging. It takes practice.

5. Don't ignore feedback, especially the stuff that's hard to hear.

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

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.

I write down my plan on paper. It's puts me in a methodical state of mind.

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

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 .

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.

Making YouTube videos to retain knowledge.

In 2020, I wanted to learn about micro-services so I made a project to learn the basics of Docker and containerize a web app.

If I went back now to read the code, I'd have no idea what's going on. Fortunately, I made a detailed video[0] explaining the workflow and I can always reference that if I want to pick up where I left off. It's also nice to see that nearly ~2k people found that video useful.

Whenever I learn a new technology/framework, I immediately make a short video about it, and I OFTEN come back to reference that video at later dates.

[0] https://www.youtube.com/watch?v=UAE85JCBrDY

What tools do you use to make youtube videos? Would you mind sharing the setup? Thanks.

Diagram: Draw.io

Thumbnails: Canva

Editing: Da Vinci (more powerful than iMovie)

Screen capture: OBS (less resource intensive than QuickTime)

Do you use a GPU for Video editing? I have read online that Da Vinci needs a GPU .Thanks.

Not OC, but I use Camtasia for screen recording and editing. Audacity for cleaning up audio. Gimp for making thumbnails.

Thanks. I am looking for free software. I think Camtasia becomes paid after the 30 days trial.

I opted to buy it. The price point is much lower than Adobe products as you don’t need a subscription. The learning curve is also much lower. You can pick up everything in 1-2 hrs

Does it need a lot of RAM for video editing? If you do not mind sharing, what are your system specs, esp if you are using windows. Thanks.

I have used it on 16GB before, but currently I use it on Windows 10 with 32GB ram, SSD drive. It works very smoothly.

Lots of good commentary in this thread.

A different take, I moved from product development into Cybersecurity Application Security and it enhanced my entire mindset around application development and building products.

It brought things to top of mind while I code that were lesser on the totem pole when in AppDev. I do not mean secure coding and remediating vulnerabilities but more holistic around building a product; security requirements, patterns, practices, etc.

1) if possible, do a rotation in Cybersecurity; specifically Application Security. This somewhat depends on what AppSec does at your company.

2) If your company has a security champion program, check that out.

I read this book: https://www.amazon.com/Computer-Systems-Programmers-Perspect...

While doing these labs: http://csapp.cs.cmu.edu/3e/labs.html

Also a colleague made me watch this from Jack Diederich: https://www.youtube.com/watch?v=o9pEzgHorH0

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

Writing about what I learn

You think you understand something until you go to write about it for others. Nothing structures knowledge in your own mind like writing about it. Nothing fills in gaps in your knowledge than being forced to write about it. Writing helps actively think through problems, helps you explain to others technical concepts. It also helps us structure programs to be readable with a writers eye. Writing helps you build empathy for others that don’t share your knowledge by forcing you into their shoes.

Keeping in mind that I'm not writing code just for an interpreter or compiler to process, I'm writing it so that other people--including myself--can read it six months later after everybody has moved on to other things and still understand what it is doing.

I just worked on some code where variables were named "poop", "crap", and "shit". How is anybody, including the original developer, supposed to know what values those variables hold?

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.

I spent a year working on GUI applications. It forced me to learn more about threading, asynchrony, and concurrency than I had in 8 years of working on back-end services.

after a long time mostly working on back-end code. It forced me to grapple with threading, concurrency, and asynchrony every day (stay off the UI thread!); I learned more

- Never be afraid to refactor code

- Never be afraid to discard code

- Try building the same thing in a new way

- Try building using the same way in a new place

leaving behind the generally toxic startup small business universe for less glamorous government work.

I spent a year working on GUI applications. It forced me to learn much more about threading+asynchrony+concurrency (stay off the UI thread!) than 8 years of working on back-end services did, and now a lot of concepts that were previously intimidating are easy.

Not worrying about the next big technology and building within the constraints you have

The actual code itself is probably the least important thing. What matters more is if it's actually working and above all, if it's solving the customer's problem.

This is true until it's no longer solving the problem. Maybe the business grows or changes and the software needs to change with them. Then the code needs to be easy to change and robust.

Detailed documentation after finishing... I find bugs and areas for optimisation when I'm forced to articulate decisions behind code months after writing it.

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.

I can think of 2 big things:

- Working at a cryptocurrency exchange for a few years. I learned a lot about databases and security.

- Starting my own business.

- Taking notes

- Write a work log and a personal log every day with learning/decisions/problems

Code reviews. Both getting my code reviewed and reviewing other's people code.

Using magit every day with a team and getting to know gnarly git maneuvers well.

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.

The thing that helped me improve is just to become always curious about the new upcoming tech stacks. That way, you will always get ahead of the pack. Practice and build side projects so that they will drastically build up your understanding.

Age, I used to suck as a younger developer.

Reply on news.ycombinator.com