3 ms·

Being able to read and write code (even in multiple languages!) is one thing, but I'd argue that the real tipping point between a junior developer and any of th

Being able to read and write code (even in multiple languages!) is one thing, but I'd argue that the real tipping point between a junior developer and any of the multitude of roles past that point is their understanding of the processes behind software development. Being able to establish testable requirements, architect and argue for/against possible designs for a solution, collaborate and help others do their jobs effectively in a team, and effectively design test cases are way bigger tells with regard to how far you've come than whatever it means to deeply understand languages. I'd even argue that hitting the books for long enough and writing enough purely hobbyist code would allow one to reach that point of deep understanding for nigh /any/ language. The same just cannot be said for those process-oriented skills, despite the fact that they're arguable of greater importance than the ability to write code itself as a professional software developer.

kochthesecond 9y ago
I am only 2.5 years into my career, and have written almost all of my teams shared libraries, security toolchain and deploy tools. I also am the sole person to maintain and develop our CI and artifact repos, do most of training of new hires in writing production code, as well as some architecture decisions. I also recently quit because I felt I wasn't being compensated enough for my efforts, in either freedom to learn/explore further, nor money. I agree with you about deep understanding and hobby code. At some point in my education, something just 'clicked' and I could see clearly that software contains no magic, only careful thought about data and trade-offs. Another part I would like to emphasize is reading (other peoples) code. Related is learning different languages and their paradigms. It is very hard and time consuming to come up with well designed techniques and patterns, and reading code let you explore this knowledge in a much more efficient manner. Also, full stack is a lie.
- hayden592 9y ago
  This. I am not quite ready to quit, but we seem almost identical.
- 52-6F-62 9y ago
  A lie, maybe... I think it's conditional. For the most part, one should specialize for performance reasons. If the project requires it, do it all -- put the whole stack together yourself -- it's not so hard to find the nuances to architecture as it once was. I prefer the pursuit of possibility. I like the adventure, but I'm a dreamer by default. And I really enjoy building something out from the first, smallest grain and seeing it grow and eventually bloom. To the parent thread: I have no idea. I run into counter opinions and situations regularly. So I just turned on the live stream from the ISS. He's (Fischer I think) outside right now and he takes turns leaving the camera on the horizon and pointing it straight down to the surface. A lot of feature on the Canadarm -- unintentionally probably.

kochthesecond 9y ago

I am only 2.5 years into my career, and have written almost all of my teams shared libraries, security toolchain and deploy tools. I also am the sole person to maintain and develop our CI and artifact repos, do most of training of new hires in writing production code, as well as some architecture decisions. I also recently quit because I felt I wasn't being compensated enough for my efforts, in either freedom to learn/explore further, nor money. I agree with you about deep understanding and hobby code. At some point in my education, something just 'clicked' and I could see clearly that software contains no magic, only careful thought about data and trade-offs. Another part I would like to emphasize is reading (other peoples) code. Related is learning different languages and their paradigms. It is very hard and time consuming to come up with well designed techniques and patterns, and reading code let you explore this knowledge in a much more efficient manner. Also, full stack is a lie.

hayden592 9y ago
This. I am not quite ready to quit, but we seem almost identical.
52-6F-62 9y ago
A lie, maybe... I think it's conditional. For the most part, one should specialize for performance reasons. If the project requires it, do it all -- put the whole stack together yourself -- it's not so hard to find the nuances to architecture as it once was. I prefer the pursuit of possibility. I like the adventure, but I'm a dreamer by default. And I really enjoy building something out from the first, smallest grain and seeing it grow and eventually bloom. To the parent thread: I have no idea. I run into counter opinions and situations regularly. So I just turned on the live stream from the ISS. He's (Fischer I think) outside right now and he takes turns leaving the camera on the horizon and pointing it straight down to the surface. A lot of feature on the Canadarm -- unintentionally probably.