I've been a professional "programmer" for 24 years, and often wish I could go back and talk to my younger self to give him some words of advice.
What's one thing you'd tell your younger (developer) self? And how would you know they listened?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (28)
Stop losing sleep, unless you’re ready to keep it up for the rest of your career (there’ll always be bugs to fix)
You can’t know everything
Your competition is “You”!
Your “happiness, life and wellness” is more than your “job”
Keep learning
You’ll be “discouraged” a lot and feel like you don’t know enough but usually you’ll be better than you were yesterday and “that’s enough”
Read documentations
Share your work
Give yourself a treat every once in a while, you deserve it !
Lastly, be kind to juniors in tech as you’d have other be to you
This resonates with me. I spent a good part of my campus life trying to compete with classmates when in reality I should have been working to make sure I get my skills better than they were the previous day. Once I figured this part out, life got way less stressful.
Wonderful tips that could really come in handy if there was an opportunity to go back in time. 🧡
I would tell my younger self to write up test scripts. The idea of automated unit tests was not something I learned about until I adopted Ruby on Rails. But I've seen their value. Namely in refactoring existing code and conveying intention. I've also seen how they can become a false positive.
Yet test scripts are not automated tests; they could be, but they don't need to be. Instead, they focus on stating "How can you verify that this is done?" As a software developer, I would likely look for ways to automate this, but the reality is not all tests need to be automated. But they do need to be remembered.
And knowing my past self, this would be a hard conversation. He was full of hubris, thinking that logic could handle all things. Which, in software, is mostly true, but we invariably make concessions, oversights, and short-cuts. It's the nature of modeling in the abstract.
What I would hopefully instill in my younger self is a sense of helping others come along in the journey of understanding the code I'm delivering. Hence the test plan.
I would definitely keep this with me. I suffer from too-lazy-to-test-personal-projects disease and this really motivated me to write tests.
Also a great write up, Jeremy. I'm wondering what you have in mind when it comes to writing maintainable and scalable code.
One of my guiding principles is "If it's hard to test, it's going to be hard to maintain and scale." So, make it easy to test.
This influences my low level decisions (make methods easy to test by using dependency injection). And also my higher level decisions (in Rails testing controllers is painful, so minimize the amount of tests you need. Which quickly becomes writing objects for actions.)
I wrote most of github.com/ndlib/sipity, and it's been the most maintainable codebase I've ever wrote. There are a few bad decisions in there based on requirements that later proved to not be necessary.
I'd emphasize the need to treat collaboration as a first-class citizen in the process, not an after thought.
I've long maintained that playing D&D since forever ago has been a key contributor to my software career. It's all about collaboration.
That is really sound advice. It's connected to taking on too much as an individual, share and collaborate.
I'm still fairly young and far from your level of experience, but I would've told my 12-year-old self to focus on a single tech discipline while still understanding the fundamentals of other tech disciplines. Wide in perspective, but deep in skill. I find that I've spent so much of my time learning different tech fields that I end up becoming a jack of all trades master of none (can't be hired), albeit not anymore.
If you want to learn programming consistently, block a amount of time in your calendar (f.e. Everyday at 6pm for 1 hour). It will become a routine and you will stick to it. That’s how I learned programming much faster.
If I could go back to the days when I was just starting to study programming, I would tell myself the most important thing:
« Spend more time with your family and friends, and do not go headlong into learning programming languages, technologies, design and other things. One day there will still come a time when, without fear of the new and unknown, you can just take and do your job, which you will like madly, but the time when native people will be around, will run away and you will never bring it back.
You will regret spending almost all of your free time at work. These thoughts will be waiting for you sleepless nights, when your code editor will be open for long hours, and you simply will not have the desire to continue creating something new, because you will try to stop time - which is merciless and incorruptible. And no matter how good a developer you are, you can't write that script, application, or just a function that can turn back time or at least slow it down. »
"You were right, the quality of developers will continue to go down, processors will get faster, storage and memory will get cheaper, and code will get sloppier and sloppier"
In what way are developers deteriorating in quality? I'm curious to know so I could prevent them in the future
I'm not the original poster, but what I've found is that there's a tendency to chase the new thing. And as such, a person loses the opportunity to reflect on the impact of what they've done. Each new thing attempts to solve the problem of the previous new thing, but itself introduces a new problem as it specifically address the previous old problem (but might have forgotten the lessons of what the previous new thing fixed).
In other words, our collective understanding of software is soft and shifting, and we're forgetting the lessons that each technology solved.
tl;dr - move fast and break things is terrible for the human condition.
That's kinda of sad.
Don't give up on your dream simply because you don't know how you belong in their story yet. There will come a day when you find your footing and everything will click into place. Wait for that day, be patient with yourself and take the time to allow yourself to grow completely. You will never regret the time and effort you put into your own future.
Take the basics more seriously you d*ckhead!
Don't sell that BTC you got paid until the price is over 30k.
Yeah!!!
Learn Haskell, but use mainstream languages at work.
What specifically is it about Haskell? Like how would you sell learning it to your younger self?
Already did it, I would just tell the younger self not to go too far.
I was drawn to Haskell as part of my search for the most powerful, safe language that I could find.
to learn English well
To care less, I cared far too much when I was younger and it caused me a lot of needless pain and anguish. No business you work for will ever care as much as you do about anything.
git only via CLI!!!
I once thought that but have come around to using magit as it cleaves close to the command line and provides a lightweight UI for applying command switches.
And boy howdy the interactive rebase is much nicer than the command-line method.
Hello my beloved fellows,
I come from the future and can tell you that everything you're saying is totally correct.
Keep on and be successful. We appreciate your work in full strength.