5 ms·
This is an excellent general framework for upping your game in software development within the context of a decent sized software engineering organization. I've
by tenpoundhammer 8y ago
This is an excellent general framework for upping your game in software development within the context of a decent sized software engineering organization. I've stumbled my way into much of this advice over the past 2-3 years.
One caveat is that much of the advice is predicated on having a supportive environment.
For Example,
> Application development is a team sport. Period. Full stop.
What if you work in an environment where people primarily work on their own? I have done a lot of that in the past.
> For many, the best way to learn is to teach.
What if there aren't feasible opportunities to teach or your management pushes a pace that makes it not plausible?
> Create side projects
There are managers that support the idea of doing side project but not the execution.
I'm sure you can find more examples of suggestions that aren't plausible in your environment.
Here is my answer to these examples, I wasn't just complaining. If you don't have opportunities to fulfill sections of this framework that you feel you are lacking in, do it anyway. If your manager tells you not to spend time learning and improving ignore them. Do it anyway.
You might say, "that's fine for you Mr. internet commenter, but I'm the one that has to take the risk". Well, that's true but I've already done it. Here were my results.
Did exactly what my management asked me to do for two straight years. All reviews for two years were "Meets expectations" with a long list of things I should improve.
One year ago, I read a book with an abhorrent title but good information "stealing the corner office"
I stopped listening to what my manager told me to do and instead I picked up random side projects with little to no perceived business value for my team, spent 10x more time reading code and made commits in projects I shouldn't be working on, and started spending a lot more time understanding basic fundamentals of software engineering.
Have had "exceeds expectations" on every review since and glowing praise.
It's counter-intuitive but, don't give the people what they ask for, give them what they want!
Note: I got a bit carried away on this comment, I should have mentioned that in reality I spend 10 - 20 % of my time working rogue, and the rest of my time doing what my boss tells me.
- azrael49 8y agoIf you don't mind me asking, what were the responses to you committing on projects without asking/authorizing, and what visible change did you make with your better understanding of the fundamentals? Do you have a book suggestion for SE fundamentals?
- tenpoundhammer 8y agoAdding to projects without authorization, is extremely popular all around, if the commit/pr is useful. My boss sees it as taking initiative, helping others, and broadening my skill set. Other teams see it as getting free work. Even when my contributions suck people think of it as a positive and often teach me the right to do the code or explain why the change is not necessary. As far as books go I don't have anything to recommend. For me improving fundamentals was really about figuring out what I didn't understand and diving in to learn it. I prefer online materials over books but one book I have read that I thought was great is 'the pragmattic programmer'. https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
- azrael49 8y agoAwesome, congrats on your success and thanks for the suggestion!
- tenpoundhammer 8y agoThanks, it can take a little while for the fruit of this approach to show up. And it doesn’t work in all organizations but I think it’s a great idea for a lot of software engineers.
- pmiller2 8y agoI’m pretty sure ignoring what my manager told me to do would have gotten me fired relatively quickly at every job I’ve ever had.
- tenpoundhammer 8y agohaha ya, my comment isn't full fleshed out. I think I got too excited. I should have added that I spend about 10% of my time working rogue which is much different than what I wrote.
- pmiller2 8y agoThat is a little different. ;) Is that 10% in addition to the 100% you were spending before, or are you spending 90% of your time doing what you’re told and 10% on other things? I’m thinking here of stuff like Googlers referring to 20% time as 120% time, and such.
- tenpoundhammer 8y agoI know many people that take the %120 approach, but I take the 80/20 approach. I have a lot of kids and volunteer a lot outside of work so I don't want to make time for 120.
- Domenic_S 8y agoI don't think it's counter-intuitive at all! Here's what I'm interpreting from your comment: * When you listened to expectations and met those expectations, you were reviewed as meeting expectations * When you met expectations PLUS did additional stuff, such as "spending a lot more time understanding basic fundamentals of software engineering", you exceeded expectations. Sounds perfectly reasonable to me! Especially since becoming better at SE fundamentals probably made you an objectively better programmer.
- tenpoundhammer 8y agoThis is a great point, except when I was meeting expectations. I talked to my manager a lot about I how could exceed expectations and followed that advice then I was still told I meet expectations. I think it's often difficult for managers to describe how to exceed their expectations, it may be a natural human limitation.