5 ms·

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It

by kenkam 13y ago

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

Ecio78 13y ago
Probably that would be the most interesting part of the story...
Stephen_C 13y ago
Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstrate the improvements. You build trust in the technology and work flow before moving on to larger more critical/risky projects. (Andy is very much missed by his former colleagues)
- j_s 13y ago
  Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'
  - Stephen_C 13y ago
    Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated. > 'This guy re-wrote all our stuff in the new hotness then left the company' The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production). I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment. As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :) (*five might not be a maximum in that scenario)
    - j_s 13y ago
      Glad to hear it worked out well; there are many times where it doesn't. Thanks for taking the time to share an overview.
- swah 13y ago
  BTW, by component you mean program, right?
  - Stephen_C 13y ago
    Yes, or a larger collection of programs/scripts/resources.
- lttlrck 13y ago
  This sounds reasonable and certainly worthwhile if it really does result in adoption in "larger more critical/risky projects." If the result was just one component out of many written in Go then the reality is it was a side-experiment and/or a poor management decision. I do hope that is not the case. "Andy is very much missed by his former colleagues" hopefully for good reasons, not because they left him with another language and toolchain to maintain :)
rubinelli 13y ago
Go has the advantage of being "Google's language." This may sound stupid, but this credibility-by-association is a very important factor for a non-technical manager.
- 0xdeadbeefbabe 13y ago
  Go puts the Go in Google.
  - gngeal 13y ago
    Without Go, you'd only ogle Google.
0xdeadbeefbabe 13y ago
No trivial feat? It seems to me that managers would be more willing to gamble than a typical programmer. But I still agree with you. I'd like to see a post about how someone switched to go from cobol.
beatgammit 13y ago
I got my boss to let me try out Go after proving that I could solve problems that we were currently struggling with. I also agree that you don't need to hire new devs. I've taken two programmers who've never used Go (mostly university languages) and taught them to be productive in a matter of days. Both consider Go to be one of their favorite languages.

by kenkam 13y ago

Ecio78 13y ago

Probably that would be the most interesting part of the story...

Stephen_C 13y ago

Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstrate the improvements. You build trust in the technology and work flow before moving on to larger more critical/risky projects. (Andy is very much missed by his former colleagues)

j_s 13y ago
Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'
- Stephen_C 13y ago
  Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting. There was a requirement for high volume/through put messaging component in our infrastructure. That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated. > 'This guy re-wrote all our stuff in the new hotness then left the company' The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production). I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment. As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :) (*five might not be a maximum in that scenario)
  - j_s 13y ago
    Glad to hear it worked out well; there are many times where it doesn't. Thanks for taking the time to share an overview.
swah 13y ago
BTW, by component you mean program, right?
- Stephen_C 13y ago
  Yes, or a larger collection of programs/scripts/resources.
lttlrck 13y ago
This sounds reasonable and certainly worthwhile if it really does result in adoption in "larger more critical/risky projects." If the result was just one component out of many written in Go then the reality is it was a side-experiment and/or a poor management decision. I do hope that is not the case. "Andy is very much missed by his former colleagues" hopefully for good reasons, not because they left him with another language and toolchain to maintain :)

rubinelli 13y ago

Go has the advantage of being "Google's language." This may sound stupid, but this credibility-by-association is a very important factor for a non-technical manager.

0xdeadbeefbabe 13y ago
Go puts the Go in Google.
- gngeal 13y ago
  Without Go, you'd only ogle Google.

0xdeadbeefbabe 13y ago

No trivial feat? It seems to me that managers would be more willing to gamble than a typical programmer. But I still agree with you. I'd like to see a post about how someone switched to go from cobol.

beatgammit 13y ago

I got my boss to let me try out Go after proving that I could solve problems that we were currently struggling with. I also agree that you don't need to hire new devs. I've taken two programmers who've never used Go (mostly university languages) and taught them to be productive in a matter of days. Both consider Go to be one of their favorite languages.