Poor man, you are out of luck. Unfortunatelly today I have the time to write a boring piece describing my saga at the current job. It can be entertaining, despite that.
Something like one year ago I called the IT director and said: - Go is a great tool, I used it at my previous job, and we have plenty of opportunity to leverage the language ecosystem here. Can I use it? - Cool! I am fine with that, of course. Just make sure your coworkers agree before we can adopt it. The next day I called my two coworkers by the time (both C++ programmers, no working knowledge of Go), and explained why I think Go brings great opportunities. I finalized by saying: - ... that's why I think we should give Go a try. I have the ok from our IT director. He told me to ask your opinion. - No. Let's keep using C++. Hahah. This last laugh was true. They coldn't hide it. Only then I understood that it would be easier to convince two turkeys to accept the importance of Thanksgiving Day. Technical choices shouldn't have an emotional impact, but for me that one had. You can bet I got a lot frustrated by that "No. hahah". I asked for the IT director for support, but he was always busy at the following days so I understood he was not willing to risk his relationship with the rest of the team only to put a smile at my face. Two months later a new IT director was hired. I called him and told why I like Go. After all my explanation I got his answer: - Yeah, that's pretty interesting, but from these new languages I prefer Rust. By that time I knew two things: 1. I would therefore use Go to my own advantage as an individual programmer, since the company I work for showed no interest at all. 2. I need to improve my sale skills, just in case I eventually loose my job and have to work as a salesman. So, I went ahead as planned, using Go only for my own tools and prototypes. When time came to put something into production I had to translate my Go code into C++ code before uploading to our official version control. Yes, that means I couldn't use some cool Go features I like, but that scheme worked well enough for practical purposes. The funny part is that the Go prototypes were faster than the C++ version. Always. Despite that, I decided not to try to convince anyone. Life is short and I was not willing to ear another "No, hahah". Go was my "not so secret" weapon, because everybody knew I used Go daily for nearly everything. I just didn't put the code under our common version control. Weeks later when I was editing some Go code a newcomer take a look at my screen and say: - Hey, guy, do you use Go?! - Yes, I do. - Man, that's wonderful. I absolutely love Go! If by any chance you stumble upon a Go project, please count me in! And by the way, that other new coworker came from a succesfull Go project at his previous job. So, I went to talk to the other guy: - Someone told me you can code in Go. - Yes! At my last job there was this legacy component, bending at an increasingly production load. They tried several alternatives, but the only solution that really worked was to recode that part in Go. It worked flawlessly. Are your using Go here? - Nothing official yet. - If there is anything I can help, please count me in. - Thanks. I could feel the passion. I was not alone. We were like girls talking about the our favorite boy band. No, not exactly, but you know what I mean. Some weeks later, at a meeting, I suggested: - we need a validation tool to share with our business partners, for them to be sure the file set they produce is ok before sending it to us. - No need to spend our precious time on such a tool. Our partners know the format and rules. Can you smell it comming? I could. So I went ahead and coded the tool privately anyways. In few hours I had a working validator, checking for more than 60 rules. When the first partner sent the file set I ran it thru my tool and found in excess of 25 thousand errors. Replied to the partner along the lines "Found some glitches. They are in the attached file. Could you fix it, please? Thanks" A week later we were still exchanging emails like that one, because "our partners know the format and rules" proved to be not enough. It becames obvious they needed a tool. So I went to my IT director and said: - I imagine you know how I could find those errors. - Yes, you have a script. - I think we could share this tool with our partners allowing them to find the issues by themselves. What do you think? - A script? They would have to install a runtime? - No. It's a Go program. Go produces an executable file. - Really? - It's a compiled language. The compiler produces native code, much along the lines of C or C++. - What do they must install to run it? Some library? - Nothing. Just the executable itself. - Hum, interesting. Ok. - By doing it I will have to upload the code to our version control. By that time he already knew we had a couple of gophers in the company, besides myself. - Of course. Go ahead. I couldn't hide the grin upon my face. That was the first time Go code was accepted into our company official repository. The gate was open. Some days later, two coworkers asked me about a change in the tool. I said: - It's simple enough. Let's do it together. I went ahead and guided them to install Go tools and implement the desired change. They were amazed it was so easy. - Where is the makefile, or project file, or whatever? - No makefile needed. You just command "go build". - Wow. The build is fast! People began to understand why I liked Go so much. They were shocked by the smartness of Go ecosystem as they learned each detail. The next improvements to our new tool were made by them. As we use to say: there is nothing like one day after another. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
