51–60 of 538 posts
A high-level design document of any significant system and subsystem is worth its weight in gold (or: programmer hourly rate * time to get up to speed on system).
This documentation will also help you in a years time when you need to either maintain that system, or need to remember how you built it so you can build something that is 90% similar to it for another project.
~13 years in: Spend your early career, to the maximum extent possible, in well-run organizations surrounded by supportive, skilled teams, so that you can optimize for skill growth and (secondarily at first, but growing over time) for individually attributable impact/ownership. Honorable mention: AppAmaGooBookSoft hire mere mortals, too, and mid-career salary expectations at them are $300k.
Interesting... I have always steered clear of such jobs because I felt I would be just a cog in the machine. It seems to me only a select few in those organizations ever shine (and most of them achieved their status before joining AppAmaGooBookSoft). Am I mistaken?
I wish I had known more about what was actually going on behind the scenes as my code executes.
In my time, I knew my knowledge was lacking, but being poor and relatively isolated I had few options. Today, factors conspire to leave new programmers largely unaware there might be problems in the first place.
Nowadays, we have way better tutorials that teach people how to use effective programming methods, but we're still failing when it comes to imparting the understanding necessary for programmers to make mindful decisions about trade-offs.
I also wish I knew more about persistence and communicating what I'm working on, it's something I'm still trying to improve. When I was just starting out, I was working on a text editor, but gave up because I thought it was superfluous. When I was about 16, I had made a pretty good game (in hindsight), but gave up on it because I thought it wasn't good enough. My life might have turned out differently if I hadn't been so shy and uncommunicative at certain points.
That nobody cares which language/stack/libs you use as long as it works.
If you really need to make software (like I do), make your own company and license/sell your work instead for >500% more than what would be your salary.
~13 years in: Spend your early career, to the maximum extent possible, in well-run organizations surrounded by supportive, skilled teams, so that you can optimize for skill growth and (secondarily at first, but growing over time) for individually attributable impact/ownership. Honorable mention: AppAmaGooBookSoft hire mere mortals, too, and mid-career salary expectations at them are $300k.
> AppAmaGooBookSoft Interesting... I have always steered clear of such jobs because I felt I would be just a cog in the machine. It seems to me only a select few in those organizations ever shine (and most of them achieved their status before joining AppAmaGooBookSoft). Am I mistaken?
The main reason I mention it is so that everyone knows to aim for a package (compensation, skills growth, interestingness of work, life happiness, whatever) which compares to a clearly achievable outcome which tens of thousands of people of similar skill levels get offered every year.
~13 years in: Spend your early career, to the maximum extent possible, in well-run organizations surrounded by supportive, skilled teams, so that you can optimize for skill growth and (secondarily at first, but growing over time) for individually attributable impact/ownership. Honorable mention: AppAmaGooBookSoft hire mere mortals, too, and mid-career salary expectations at them are $300k.
When I started out I had a horror of working in a large organisation. Worked for Ericsson for a year, but the size of it appalled me and I left. I've learned since that if you are smart and get shit done then you're probably best off climbing the ladders a big corp has, rather than churning out code for one small shop after another hoping they'll hit the big time
Looking back 24 years, I'd also add, to be more involved in the local hacking community and participate in hackathons.
Anybody can code, but to make a difference, you need to network ;)
- get a mentor. Some chilled senior guy with lots of experience. Speak to him regularly to fish for knowledge. But don't get hung up on everything s/he says. Programming is huge field with lots of parts.
others:
- there is no silver bullet
- simple is not easy (search Simple Made Easy by Rich Hickey)
- always be pragmatic
- there are indeed better approaches than OOP, which differ greatly in long run of project, and pay back (FP) later, and it matters
- avoid "the chase" of latest best-good thing, get productive in something that matures well
- don't ignore latest practices and latest progress just because of the above mentioned things. Keep learning and try to reapply new stuff (at least in your head) to range of problems you solved, and think if pro-s and con-s.
- avoid any heated discussions about languages
- keep your ego out of work
- the less you need to code, the better. You are paid to solve problems, not to churn code.
- finished is better than perfect. Don't gold plate your solution. On flip side, don't code shit and try to excuse it with above-mentioned sentence. Be pragmatic.
- types are your friends (and friends of your colleagues that have to work with your code), take time to learn how to leverage them
- unless you're working on life critical software, don't stress (even then don't, but...). If you feel pressure and stress, work on handling that. There is no point in being miserable because someone needs ability to put dog face onto a photo.
- you'll be programming for a lot more years to come. You may genuinely like and enjoy it throughout that period, or hate it. If you hate it, it doesn't mean you're not suited for programming, maybe you're not using language that suits you or allows you to express yourself clearly. Yes, people say languages don't matter. From your perspective as programmer, they do (they don't for business as long as it gets job done etc.).
- learn new language at least once per 1-2 years. No need to use it, just get familiar with it, it's design choices, it's public APIs, some internals. Language creators are generally very smart and you can learn from them a lot.
- Once you're a bit more senior learn from other (junior) devs. They're the ones usually chasing latest hot frameworks. They have time for that. Be appreciative about that, and take your time to listen to what they have to say, and what excites them, and how it relates to your experiences. It is also opportunity to grow.
- Try to contribute to open source projects. Not to build portfolio, github or whatever. But to give back some of the service. You'll be paid back by learning a lot.