Re:Rockstar shopping is inherently unsafe (2015)
by singingfish on Saturday April 07, 2018 @06:44AM
(#16780208)
I got hired as a backend "rockstar" a few years ago. Didn't work well.
1. I made some mistakes (my general response to said mistakes was to work to ensure the CI tool guaranteed said mistakes couldn't be repeated. Included kicking up CI into the process in the first place by fixing their test rot and enabling someone else to bring jenkins into the mix). One of those mistakes did cause a recoverable partial outage.
2. The extensive unfucking of the backend I performed still hasn't been applied, despite pretty clear demonstration of the safety of said changes . One of which if eventually applied will reduce their AWS bill by 10-20% - I produced a demo that this was safe bug-for-bug. A spectacular security hole that was there is gone, so that's a plus.
I got retrenched (made redundant with a small payout once I pointed out that was what was needed). I went into the conversation to say "I'm going to need more money and we need to work out a process where my work gets applied", but the retrenced bit happened really early, so I never got to propose that :) . I had an offer within an hour of being retrenched. Currently I unfuck code at a similar scale for a larger concern and get reasonable career development opportunities. The place I was working for has been hiring junior devs like crazy, so I do worry about the health of their codebase - having said that when in their comfort zone the senior guys there are pretty good. I think the problem was that I was getting the senior guys out of their comfort zone, and I didn't take a sufficiently gentle approach. However I learned heaps, so all good. Can't imagine I'll be going back their though.
Re:Rockstar shopping is inherently unsafe (2015)
by singingfish on Saturday April 07, 2018 @05:02PM
(#16782953)
Tone deaf to what? Oh yeah it was absolutely the right thing to happen, it wasn't working. That's not quite the same as "deserved to let go". I suspect any senior developer person with an architectural remit and fair breadth of experience would have the same problems there.
Re:Rockstar shopping is inherently unsafe (2015)
by wink on Sunday April 08, 2018 @04:47PM
(#16788286)
Sometime it just doesn't fit, but what you're describing is what often happens if the organization is not listening. Sure, some people charge in and exclaim everything sucks in their first week, but if the org isn't accepting objective improvement sometimes it's better to just run instead of fighting windmills.
Re:Rockstar shopping is inherently unsafe (2015)
by singingfish on Sunday April 08, 2018 @06:23PM
(#16788826)
Yeah one of the mistakes I made was taking the "everything sucks" approach too early and too often. I don't think that taking a different approach would have helped though. Sometimes I think it takes (near-)complete turnover of the original implementation team to make things suck less.
Re:Rockstar shopping is inherently unsafe (2015)
by YZF on Saturday April 07, 2018 @03:35PM
(#16782390)
A big hurdle is that when you hire the first dedicated person into a new domain (be it UX, Embedded, Security, EE, Legal, Finance whatever.) you often don't really understand the domain well enough to know what you need. You should also be thinking that rather than this person doing all the work themselves they should be educating the rest of the company in this area. They need to be experts, they also need to be good "people" people. You probably already got lots of "not experts" in those areas ;)
Security is very multi-faceted. Securing your internal/IT applications is very different than writing secure code which in turn may be different than some other specialized situation. Ideally you already have some people who have some clue and/or have seen something that works somewhere else from an organizational perspective (or have seen things that don't work that you don't want to repeat). E.g. you may have some IT person who isn't a security expert who has worked in a team that had a stronger security bias/expertise and has seen how that team worked/was structured. You may have a senior coder who has pretty solid ideas about security but it's not his main expertise. Leverage that stuff! Talk to those guys about how to build the team...
1. I made some mistakes (my general response to said mistakes was to work to ensure the CI tool guaranteed said mistakes couldn't be repeated. Included kicking up CI into the process in the first place by fixing their test rot and enabling someone else to bring jenkins into the mix). One of those mistakes did cause a recoverable partial outage.
2. The extensive unfucking of the backend I performed still hasn't been applied, despite pretty clear demonstration of the safety of said changes . One of which if eventually applied will reduce their AWS bill by 10-20% - I produced a demo that this was safe bug-for-bug. A spectacular security hole that was there is gone, so that's a plus.
I got retrenched (made redundant with a small payout once I pointed out that was what was needed). I went into the conversation to say "I'm going to need more money and we need to work out a process where my work gets applied", but the retrenced bit happened really early, so I never got to propose that :) . I had an offer within an hour of being retrenched. Currently I unfuck code at a similar scale for a larger concern and get reasonable career development opportunities. The place I was working for has been hiring junior devs like crazy, so I do worry about the health of their codebase - having said that when in their comfort zone the senior guys there are pretty good. I think the problem was that I was getting the senior guys out of their comfort zone, and I didn't take a sufficiently gentle approach. However I learned heaps, so all good. Can't imagine I'll be going back their though.
Security is very multi-faceted. Securing your internal/IT applications is very different than writing secure code which in turn may be different than some other specialized situation. Ideally you already have some people who have some clue and/or have seen something that works somewhere else from an organizational perspective (or have seen things that don't work that you don't want to repeat). E.g. you may have some IT person who isn't a security expert who has worked in a team that had a stronger security bias/expertise and has seen how that team worked/was structured. You may have a senior coder who has pretty solid ideas about security but it's not his main expertise. Leverage that stuff! Talk to those guys about how to build the team...
Prince saying "I need a camel" in the middle of the night on Chanhassen, MN?
https://www.youtube.com/watch?v=nY4isQVSgDg