> People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer.
That goes for all those talking heads on youtube too btw. They're not necessarily right, but they're good speakers/actors.
Advice for new software devs who've read all those other advice essays
41–50 of 361 posts
Re: Advice for new software devs who've read all those other advice essays
#42Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…
Many people's brains cannot absorb that much information. If I sat down and read full docs front to back I would remember maybe 3 things. I don't think this is overall practical advice. Then reading the source code too for all this stuff I like? I don't understand where one finds the time for all this? I'm not putting you down, I just genuinely am confused. I barely get my stuff done as it is each day haha
Re: Advice for new software devs who've read all those other advice essays
#43Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…
There are some brains that do very well with this advice, but mine is not one of them. I only seem to learn by moving back and forth between solving a real problem and finding just enough information to move forward one step. After some period of this, I'm usually able to read (and understand) a book or two on the subject, but never before. Maybe I'm a tactile learner? Not sure what to call it, but if you're not sure…
Same here. If I were to read docs cover to cover, not much would stick in my brain. I need top down research, start high level, and drill down where ever I touch base with practical applications. It's why I find interacting with LLMs so pleasant (ignoring their shortcomings), because I can learn exactly the way I want to and the way that works well for me.
Re: Advice for new software devs who've read all those other advice essays
#44Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…
Work fragmented my brain so much as I am into so many things at one time and I am sure a lot of us feel like this. This comment makes me think on how to actually do that and how much time and efficiency this would cost. Nevertheless there is truth in it. How do you manage this?
Not OP, but that's how I do it (non-software stuff, but tech documentation is complex for any product, and if it is not there is no real problem):
- get someone on the team to give an introduction to get some basic knowledge of the system in question, where to find things and what portion of the system affects you
- read the documents relevant as per the previous point
- read cited documents
- start working, and look up stuff everytime you have to, dig as deep as possible
- unless you are 100% sure about something, look it up
- rinse and repeat, that grows your knowledge from immediately relevant stuff, to related stuff to general knowledge of the system
- ask question, always, be curious, listen, read and ask questions
It is a team sport, you don't have to know everything, master your stuff, and your interfaces with others (functions, sub-systems, teams and people, get a solid understabning of the overall system and relly on other like you for there parts.
Going alone, based on gut feeling and assumptions is not something I'd advice.
Re: Advice for new software devs who've read all those other advice essays
#45Earlier quoted context omitted.
Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all…
How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…
Because mental capacity is finite, and knowing as much as possible doesn't work for everyone, especially if it's disconnected from actual problem solving. Reading a book cover to cover and have everything in there stick in the mind is great if it works for you, but there are plenty where it does not.
Re: Advice for new software devs who've read all those other advice essays
#46Earlier quoted context omitted.
Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all…
How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…
Is it laziness or is it the fact that brains are different and many people (me included) can't absorb that much material and then retain it as well with so many other things going on in our work/lives. I would struggle just to read the entire docs, front to back, of anything in a sitting. Then to retain all that?
"lulz" -my brain
Re: Advice for new software devs who've read all those other advice essays
#47Earlier quoted context omitted.
Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all…
How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input f…
How much is it possible to know about the systems? The app I work on now uses MariaDB (multiple versions at this point), postgres, Cassandra, and InfluxDB. Those are just the databases I can recall offhand; there may be others and there were others before my time at the company. And those are just the databases. I’m also responsible for hardware, networking, cloud infrastructure to include IaaS and container orchestration plus tons of services. Say it I should read the docs on all that is like a cruel joke. Not only are there not enough hours in the day, I doubt there are enough years in my life to imagine such a task. And it would be Sisyphean anyway because at any given moment one of them will make a “minor” update that breaks functionality and a bit of my knowledge will be useless. Welcome to the world of postmodern system administration; I guess we call it DevOps or SRE now or something; even that’s a philosophical debate these days.
Re: Advice for new software devs who've read all those other advice essays
#48The first item is also why it's good to be skeptical about things you learn on video sharing services like YouTube too. If you sound credible and present your ideas in a professional way, people will take them seriously regardless of how flawed they might be. In a world where a fair few 'essayists' have been exposed for just reading Wikipedia articles and Reddit posts, it's definitely good to try and not associate how people present their ideas with how accurate said ideas are.
I'd also expand on point 10 to add that talking to these people often gives you a better picture of what problems your software/dev work is trying to solve, and can help you identify pain points that you may not have noticed yourself. Remember that with a (very few) exceptions, software isn't written for the sake of it, it's written to solve problems.
Either way, nice list! Definitely has some useful advice there.
Re: Advice for new software devs who've read all those other advice essays
#49Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your…
Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc.
Advice like that above is honestly terrible for newer developers, I believe. It feels insurmountable for many people, myself included. I simply don't have the brain capacity to:
A. Read an entire language's docs front to back. As you mentioned, maybe if it is some small, silly thing but for something like Python, Java, JS, etc... no fucking way. My brain would constantly glaze my eyes over. There is so much.
B. Retain the information I just attempted to read. Again, there is so much. It's insanely unrealistic for most people, I would think.
New developers see advice like this and immediately feel like they aren't cut out for this because people make this nonsense sound like something 'YOU MUST DO' to be a good developer. It's toxic, in my opinion. Maybe not intentionally so, but it really can kill a person's excitement.
Re: Advice for new software devs who've read all those other advice essays
#50My best bit of advice for any programmer at any level: "Don't make stuff more complicated than it has to be!" Software is complicated. Large, feature rich software is even more complicated. That's hard enough to manage as it is. The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. E…
I think an automatic code formatted actually makes one’s job easier, not more complicated.