21–30 of 70 posts
When you get a job this behavior will be inverted. You'll know how to write software but you'll have to spend more time learning the domain.
If you are naturally really good with computers and can already program, make sure you learn to work with other people. There is, happily, quite a lot of info out there to help borderline autistic types (like me) learn to come across like a normal person. I can provide more info if anyone needs it.
- Don't ever be pressured into regularly working overtime because someone claims you're not "passionate". You're entirely welcome to only program during work hours
- Learn to use a debugger well
- When a user has an issue with your software, make sure they give you a step by step recount of how the issue occurred
- Unit tests may seem like a waste of time, but are unfortunately very useful
- Find a niche you enjoy. If you're developing software you're not interested in, you're going to quickly burn out
- Don't always chase the new and shiny technologies (unless you're really interested in them), many of them will never become successful.
- You don't have to be the next Zuckerburg to be successful. You can make a very comfortable living as a developer doing a job you enjoy, don't constantly chase trying to become a billionaire and focus on progressing your career via the usual channels
I'm fairly poor at the second so all I'll say is that being good at the politics/communication becomes more important as you become more senior and is ultimately more important for your career than being good technically.
Technically, the most important thing I learned after I graduated is that state is the most important thing in production systems. Programming paradigms, system architectures, and design patterns are all rooted in managing state. Almost always by constraining it.
For me the critical talk on this was Rich Hickey's "Are We There Yet" but I'd been writing functional code for a couple years when I saw it. When I've directed people to it they find it weird/confusing and have more success with "Simple Made Easy" which I find similar but less insightful. A focus on state first has been the cornerstone of my development philosophy since 2009. It's not universal (e.g. data oriented design) but it's my one weird trick.
I'm a visual thinker and visualize a piece of state as a gas that leaks through calls and variable scope. If it's in the database it leaks through queries accessing the table and the services that expose it. The fewer things state touches, the better because people fundamentally are terrible at understanding interactions over time (e.g. three body, double pendulum). Seeing the state flow through the system tells you how well it's designed/built and where the problem points are.
Imposter syndrome is real. Kinda soon you'll be in a position where others look up to you, thinking they'll never get as good as you, while you still think you're a total noob. If coding, don't do everything from scratch. I've seen multiple people losing interest in their projects, because they didn't even really start them. It's almost always parsers, they (my old me included) write their own parsers for stuff and t…