Earlier quoted context omitted.
I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good engineer. Wrote good-enough code. But he wasn't precious about anything and he didn't care all that much about finding the 100%-guaranteed-socially-approved-correct way to do things. What he had was an incredible ability to diagnose and fix problems quickly, str…
In my experience it is useful to have such people on the team, but if they make up most of the team then the codebase becomes a gigantic mess over time, and it negatively impacts everyone else.
What I learned working with a senior engineer as a new grad
191–199 of 199 posts
Re: What I learned working with a senior engineer as a new grad
#192Re: What I learned working with a senior engineer as a new grad
#193Earlier quoted context omitted.
This is true. I'm just responding to OP though, they said: > Yeah its pretty scary, 6 years mean you've either only understood on one or two big systems, or you've job hopped more projects and never understood them in depth. Which is blatantly false. I only need to provide one counterexample, and John carmack blows this assumption out of the water. I wouldn't expect the average developer to be anywhere near that leve…
language is more fuzzy than binary logic systems, John Carmack is an exception rather than a counterexample. And that's the point, comparing exceptional people to the general population isn't valid or relevant here. Also, these people are typically on teams as juniors who are learning. Consider that you immediately reached for someone who is over 50 as an example of a developer having a large impact in the first 5 ye…
An exception is a counterexample. For example, are all prime numbers odd? No.
Why not? Because 2 is prime and even. This is exceptional because 2 is only 1 out of a (theoretically) infinite number of prime numbers that are even. This doesn't mean I can now say, "All prime numbers are odd".
The OP gave a tautology that basically went, "If you've only had 6 years of experience, then you only worked on 1 or 2 big projects OR you've job hopped and have a low level of understanding". John Carmack is exceptional, but also a counterexample to this statement in both regards. He was also the lead programmer at ID when he made Doom, not a junior.
Besides this point, what does him being over 50 have to do with this? He was 19 when he started working professionally if I remember correctly, which means he was 24 by the time he made several significant industry impacts.
Besides that point, here are some more counterexamples to the original claim. Mark Zuckerberg was 19 when he started Facebook. Alan Turing was 29 when he cracked the enigma. Djikstra invented Djikstra's algorithm when he was 26. Bill Gates founded Microsoft when he was 20 and released Windows when he was 30. I have plenty of personal examples as well, but it wouldn't do any good to mention them since they're not famous programmers.
Re: What I learned working with a senior engineer as a new grad
#194Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.
The recommendation I read back in the 90's in Code Complete that has served me well ever since was that variable name length should be roughly proportional to the variable span. "Variable span" being the distance between where the variable is first defined and its last use. Generally that means that a temp variable inside a short function can be a single letter since you can see the full context of its entire lifecyc…
Re: What I learned working with a senior engineer as a new grad
#195Earlier quoted context omitted.
language is more fuzzy than binary logic systems, John Carmack is an exception rather than a counterexample. And that's the point, comparing exceptional people to the general population isn't valid or relevant here. Also, these people are typically on teams as juniors who are learning. Consider that you immediately reached for someone who is over 50 as an example of a developer having a large impact in the first 5 ye…
> language is more fuzzy than binary logic systems, John Carmack is an exception rather than a counterexample. An exception is a counterexample. For example, are all prime numbers odd? No. Why not? Because 2 is prime and even. This is exceptional because 2 is only 1 out of a (theoretically) infinite number of prime numbers that are even. This doesn't mean I can now say, "All prime numbers are odd". The OP gave a taut…
you're insisting on 2-valued logic, language does not work that way.
---
Here's what you're doing.
"seat belts save lives, therefore you should wear them".
"aha! There was this ONE car wreck where they would have died if they were wearing their seatbelt. It's a counter-example and therefore invalidates your point!."
Said no reasonable person, ever. What it IS is an exception to the general rule. Because it turns out, reality isn't 2-valued.
Re: What I learned working with a senior engineer as a new grad
#196Earlier quoted context omitted.
> language is more fuzzy than binary logic systems, John Carmack is an exception rather than a counterexample. An exception is a counterexample. For example, are all prime numbers odd? No. Why not? Because 2 is prime and even. This is exceptional because 2 is only 1 out of a (theoretically) infinite number of prime numbers that are even. This doesn't mean I can now say, "All prime numbers are odd". The OP gave a taut…
Since you're insisting on putting it into mathematical terms, here it is. you're insisting on 2-valued logic, language does not work that way. --- Here's what you're doing. "seat belts save lives, therefore you should wear them". "aha! There was this ONE car wreck where they would have died if they were wearing their seatbelt. It's a counter-example and therefore invalidates your point!." Said no reasonable person, e…
Reality is not 2-valued. I don't understand why you're still arguing this point. Yes John Carmack was exceptional. And yes it's true that 6 years of experience does not automatically imply a junior level of experience. That's all I'm saying here.
Re: What I learned working with a senior engineer as a new grad
#197Earlier quoted context omitted.
Since you're insisting on putting it into mathematical terms, here it is. you're insisting on 2-valued logic, language does not work that way. --- Here's what you're doing. "seat belts save lives, therefore you should wear them". "aha! There was this ONE car wreck where they would have died if they were wearing their seatbelt. It's a counter-example and therefore invalidates your point!." Said no reasonable person, e…
"Seat belts always save lives" vs "seatbelts save lives". The first is false according to your counterexample, and the second is true as long as seat belts save some lives. Reality is not 2-valued. I don't understand why you're still arguing this point. Yes John Carmack was exceptional. And yes it's true that 6 years of experience does not automatically imply a junior level of experience. That's all I'm saying here.
Re: What I learned working with a senior engineer as a new grad
#1986 years of experience does not make one a senior engineer. I`ll be polite and say that most engineers with 6 years of experience I know are not seniors.
As pointed here, it is rare to work on interesting and trail blazing stuff - that's why it takes time, sometimes years, to gain the experience. There's a low probability of actually working on something meaningful, therefore you have to fight it with repeated attempts of finding the interesting stuff - and that takes time. Obviously, time is not the only thing needed to become a really experienced engineer, but - in almost all cases - its a prerequisite.
Re: What I learned working with a senior engineer as a new grad
#199Earlier quoted context omitted.
I don't mind "i", but if there's an inner loop with "j" as well, you are BEGGING for confusion.
I got down to "k" too. What about "x" and "y"? One important consideration of nested loops is row major access pattern rather than column major pattern, so access array[i][j] rather than array[j][i] due to the data locality of each. You shall get a performance boost by accessing them in that order. I worked on parallelizing nested loops across OS threads and load balancing between outer loops for different progressio…
`i` and `j` are usually indicative an index for something, and indicating what you're indexing makes the code clearer to read and easier to maintain. `idxUsers`, `idxPosts`, for example. `x` and `y` are a bit trickier because they're very frequently the canonical positional co-ordinates, and renaming them can actually make it _harder_ to read, so (like all things in naming) is a real judgment call, but frequently can be replaced with `col` and `row`, which, to me reads _much_ clearer, especially when using row-major access pattern: `array[row][col]`.