4 ms·

Take the time to understand the whole system you work within, not just your little stovepipe. That system may not be technical, but procedural. It will include

by jjguy 10y ago

Take the time to understand the whole system you work within, not just your little stovepipe. That system may not be technical, but procedural. It will include other business functions. It may include your customers. In any system, there is a clear "start" and "end" that encompasses a complete process and reason for being. You'll find that in most organizations, people stay in their little corner, do their little thing, not caring much about what happens to the left and right of them. That leads to inefficiencies and missed opportunities. If you understand the larger system, you'll be able to see opportunities others are blind to. Point a couple out and -if you're both respectful and right - it won't take folks long to think "man, this guy really gets it!"

xs 10y ago
I like this a lot. When I first became engineer I went to our infrastructure team to have them explain to me what every tool we have does and how it fits into what we do. It took a few weeks but at the end of it, I could see the way the business ran much clearer than I did before. This helped me tremendously over the next few years.
ihsw 10y ago
To expand on this -- understanding a level of abstraction both above what you're working on and below it. For example, if you're working on the back-end, an understanding of how front-end developers (or, more to the point, API consumers) will be using your services goes a long way to doing work well. Similarly, a minimal understanding of database engines goes a long way too. While premature optimization can bite you in the ass, simple fowl-ups like N+1 queries can be avoided by learning just a little more. Writing well-structured code that is debuggable and loggable works well too, for when someone else is looking at your code. Reducing and preventing code smell[1] will prevent unpleasant bugs from cropping up. This can be summed up as the boyscout rule -- leave your code better than you found it. [1] https://en.wikipedia.org/wiki/Code_smell https://en.wikipedia.org/wiki/Code_smell
spcelzrd 10y ago
This advice echoes the first chapter in The Passionate Programmer. Recommended.
sampl 10y ago
A great way to do this: join a small startup. I did, and I learned more in the first week than I could have ever hoped to at my old job. Also related: https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-the-table https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-th...
- shados 10y ago
  assuming both the startup and the "big company" you compare it to are great in their respective categories, I find it to be a wash. My career was split pretty 50/50 between startups and big companies (about half dozen of each as my sample size), I found them to be similar in term of learning. You just learn different things. At a startup you're more likely to do everything and wear all the hats, see things from the beginning and build stuff from scratch. That also means you don't get to see as much of how tech debt can be efficiently paid off, how to maintain large systems, or can't have the hindsight 20/20 of all the solutions to problems startups face. My early careers was mostly startups, and I felt I had learnt a ton. Then joined bigger highly successful tech companies, and realized there were much better ways to do everything I had seen (solutions that would have worked at the startup scale in many cases)

by jjguy 10y ago

xs 10y ago

I like this a lot. When I first became engineer I went to our infrastructure team to have them explain to me what every tool we have does and how it fits into what we do. It took a few weeks but at the end of it, I could see the way the business ran much clearer than I did before. This helped me tremendously over the next few years.

ihsw 10y ago

To expand on this -- understanding a level of abstraction both above what you're working on and below it. For example, if you're working on the back-end, an understanding of how front-end developers (or, more to the point, API consumers) will be using your services goes a long way to doing work well. Similarly, a minimal understanding of database engines goes a long way too. While premature optimization can bite you in the ass, simple fowl-ups like N+1 queries can be avoided by learning just a little more. Writing well-structured code that is debuggable and loggable works well too, for when someone else is looking at your code. Reducing and preventing code smell[1] will prevent unpleasant bugs from cropping up. This can be summed up as the boyscout rule -- leave your code better than you found it. [1] https://en.wikipedia.org/wiki/Code_smell https://en.wikipedia.org/wiki/Code_smell

spcelzrd 10y ago

This advice echoes the first chapter in The Passionate Programmer. Recommended.

sampl 10y ago

A great way to do this: join a small startup. I did, and I learned more in the first week than I could have ever hoped to at my old job. Also related: https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-the-table https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-th...

shados 10y ago
assuming both the startup and the "big company" you compare it to are great in their respective categories, I find it to be a wash. My career was split pretty 50/50 between startups and big companies (about half dozen of each as my sample size), I found them to be similar in term of learning. You just learn different things. At a startup you're more likely to do everything and wear all the hats, see things from the beginning and build stuff from scratch. That also means you don't get to see as much of how tech debt can be efficiently paid off, how to maintain large systems, or can't have the hindsight 20/20 of all the solutions to problems startups face. My early careers was mostly startups, and I felt I had learnt a ton. Then joined bigger highly successful tech companies, and realized there were much better ways to do everything I had seen (solutions that would have worked at the startup scale in many cases)