<p>Hey there. Not sure that this is a right place, but I would be really grateful for your insights :)</p>
<p>I've been in mobile development for about 4 years now, I've reached a certain level of seniority and currently, I am working in a unicorn. I would not say that I've become top-notch Android engineer, but definitely above average.</p>
<p>The thing is, I got bored. Android development just does not bring enough challenge for me, and, oh Lord, I am tired of UI. So I've been thinking about changing my field to server-side development, in particular, with Go.</p>
<p>The problem is, I have no idea how to execute the switch of the niches. I can learn Go(actually I am already pretty comfortable with it), but backend is so much more than just a language. What things should I look into, what kind of pet projects should I make?</p>
<p>Perhaps, some of you have walked a similar path and I would love to hear from you.</p>
<p>Thanks!</p>
<p>EDIT: Wow guys. I've never expected so much attention and help from you. The community is definitely one of the most beautiful things about Go :)</p>
<hr/>**评论：**<br/><br/>arp242: <pre><p>I got hired at my current job as a Go programmer with no previous Go experience. I got hired at my last job as a Ruby programmer with no prior Ruby experience.</p>
<p>Some companies <em>will</em> look for buzzwords to "tick off" their list, but many don't and are simply looking for good programmers. Being productive in a new language is relatively easy for most languages (it certainly is for Go), although true mastery usually takes a bit longer.</p>
<p>I also left school at 16, worked minimum wage jobs for a few years, and didn't have my first programming job until I was 26. Not a carreer path I would recommend anyone take, but it does demonstrate that background and a "traditional" CV isn't everything.</p></pre>Kistamushken: <pre><p>Oh, this is inspiring, man, thank you for sharing your story :) I can partly relate to that, as I do not have any technical degree and worked as a salesperson for a couple of years, landed my first software job when I was 23 or 24.</p>
<p>You are right, if you are decent developer picking up a new language is easy(well, at least this is true for languages that share the same paradigm). What concerns me more is the ecosystem of the certain niche, like frameworks, tools, etc.</p></pre>joffuk: <pre><p>My route was fairly similar, after failing horribly at school I spent a few years cooking in a few different pubs and restaurants then did a 5 year stint selling tools and other junk.</p>
<p>I got lucky and got hired as web developer for a company site which then led to a Support role with some dev helping out some of the top FTSE 100 companies with security and file transfer automation.</p>
<p>After 4 years there I moved on to supporting one of the leading print management solutions and looking into bugs and now I spend my time dealing with really odd support issues and writing integrations between systems using Go.</p></pre>Ainar-G: <pre><blockquote>
<p>The problem is, I have no idea how to execute the switch of the niches. I can learn Go (actually I am already pretty comfortable with it), but backend is so much more than just a language. What things should I look into, what kind of pet projects should I make?</p>
</blockquote>
<p>That really depends on what kind of backend job you want, but here are some pointers:</p>
<ul>
<li><p>HTTP, especially HTTP/2, + WebSocket</p></li>
<li><p>modern databases, e.g. PostgreSQL + key-value storages, e.g. Redis</p></li>
<li><p>some basic Linux/Unix administration (ulimit, bash scripts, etc)</p></li>
<li><p>tools, like profilers, debuggers, especially static analysers</p></li>
</ul>
<p>As for toy projects, the simplest thing, that can also be challenging and interesting, is a forum/blog platform. Make something basic, and then add as much as you want: authentication, caching, administration tools, JSON API, tags, real-time updates (e.g. new comments), rate limiting. Then also race against yourself with profiling.</p></pre>fmpwizard: <pre><p>This is great advice, I would just add that you don't need to know everything about backend development to make the switch. Today there are things I still don't know and next month/week I know them. As long as you are good at learning, I would say you are all set.</p></pre>jonbonazza: <pre><p>First of all, as a backend engineer at any reputable company, the odds of you programming exclusively in Go for the duration of your employment are extremely slim.</p>
<p>Now onto your main question. "server side programming," also called "systems engineer" or "back end development," uses many of the same programming paradigms and concepts as other specializations. A firm understanding of things like parallel processing and "multi-threaded" programming and its various forms is pretty much necessary, as is a solid grasp on things like synchronization primitives and what-not. Another major concept that you'll need to understand is <em>scalability</em>. In ages past, scaling <em>vertically</em> was the norm, where you simply threw resources at a host until you had enough. These days, systems are typically designed to be <em>horizontally</em> scalable, where you have multiple instances of each application running in parallel and depending on the use case, these instances might run independently of one another, or they might need to all know about each other and work together towards a common goal. With this paradigm shift came the requirement that engineers at least have a basic understanding of the various concepts and algorithms for things like high availability, data replication, consensus, and intra-cluster communications. Caching strategies are another very important aspect of back end development, as network communications are inherently slow (relatively speaking) and costly. </p>
<p>This is all just concepts for back end <strong>development</strong> so far, but the reality is that <em>most</em> back end engineering jobs will require you to take on at least some Ops roles as well (Some companies expect their developers to do double duty and perform development <strong>and</strong> ops at the same time. These roles are typically called "dev ops."), so things like basic linux server administration (VMs, containers, w/e) and knowing your way around the shell and basic linux tools is also important, but I digress.</p>
<p>There are loads more concepts that back end engineers will typically utilize in their day-to-day, but there is really no way that you can expect to learn <em>everything</em> before landing your first back end gig. Much of what I have already mentioned will be learned with experience and time on the job. </p>
<p>The one thing you will have to accept when switching from one specialization to another is that your title will likely not transition over. For instance, if you are currnetly a "senior" software engineer, then you will probably land the new gig with something like a "mid-level" software engineer title (or w/e that company calls it). Unfortunately, this also often results in a pay cut. In this particular case, you might get lucky, however, as back end engineers <strong>typically</strong> get paid more than mobile or front-end engineers, so it might even out in the end, but I wouldn't bank on it.</p>
<p>Source: I am a back end engineer for a popular global engineering company.</p></pre>Kistamushken: <pre><p>Thank you a lot for such comprehensive answer.</p>
<p>Yeah, currently I am digging into microdevice architecture and Docker, I believe today it is a crucial part of being back end engineer. Well, at least, if you are not working in some pure monolith type of a project, but even these projects are trying to break down their monolith today.</p>
<p>As for the titles...Well, I do understand the risks here, but software development is just so much more for me than a title or a paycheck. I am just incredibly passionate about it. Therefore, if it brings me the joy of learning/struggling with new stuff, I am more than ready to sacrifice some fancy titles :)</p></pre>deusmetallum: <pre><p>I'm going through a similar transition from the systems end. I've always been a systems administrator, but writing applets in go has made my job easier, and I want to do more go dev in future.</p></pre>Kistamushken: <pre><p>Yeah, same here I guess. I am also trying to incorporate Go into my daily stack, though for now, these are pretty little things, mostly CI related stuff</p></pre>deusmetallum: <pre><p>If I were to give you any direction from a systems point of view, I'd suggest looking at all the tools Hashicorp have created.</p></pre>Kistamushken: <pre><p>Thank you! That is very interesting, will have a look</p></pre>Southclaws: <pre><p>I fell into a backend position at a startup and really got into cloud stuff with Kubernetes. It seems like that kind of thing is becoming high-demand and the single-server or machine-specific kind of work only applies to either legacy projects or really small websites (from my experience anyway). Everything else is in AWS/GKE/Azure running possibly hundreds of stateless instances of tiny one-job applications which are all talking to each other, crashing, respawning, being scheduled/managed/scaled by other applications. That clusterfuck of interconnected spaghetti is what really gets my brain going!</p>
<p>So, if that sounded kind of interesting, GKE literally give you free servers to learn their product so write a basic app and deploy it to Kubernetes then scale it up, watch it break and figure out how to make it scalable, stateless and future-proof!</p>
<p>If you like the sound of Kubernetes itself, you can write plugins for it that control the behaviour of how it makes decisions such as where to schedule apps and how to handle failures etc.</p>
<p>If that's not your cup of tea, you could try building a simple API driven webapp based around a side-hobby, for example I made a <a href="http://samp.southcla.ws">game server list</a> API in Go and then used it to learn ReactJS to write a frontend to visualise the data.</p>
<p>Hope that helps brew some ideas :)</p></pre>Kistamushken: <pre><p>That definitely sounds really interesting. Actually right now I am thinking about implementing simple messenger app with Android frontend. This should cover Websocket connection and much more. </p>
<p>To be honest, for now, I don't have any experience with K8s, well, I know the purpose of it, just haven't worked with that. This definitely goes on my todo list. Thank you so much!</p></pre>jocull: <pre><p>May I ask why Go? You must have lots of Java experience and there's tons of work to be done server side with Java or another JVM language like Kotlin, Scala, Groovy, or whatever is cool these days.</p>
<p>Just asking since I believe the JVM job market is much larger. Some may mix Go in for particular cases if you want both.</p></pre>Kistamushken: <pre><p>Well, yeah, you are right. Guess, I just miss that junior feeling :) I do have lots of experience with Java and Kotlin.</p>
<p>Actually, since companies with exclusively Go stack are somewhat exotic, I was thinking about companies who have JVM stack and doing some Go microservices in addition.</p></pre>cjbprime: <pre><p>You've already got lots of good advice about thoroughly understanding TCP and HTTP, so I'll add this:</p>
<p><a href="https://pdos.csail.mit.edu/6.824/labs/lab-raft.html">https://pdos.csail.mit.edu/6.824/labs/lab-raft.html</a></p>
<p>It's an MIT lab that has an exercise where you build a Raft implementation in Golang and it gets tested by their own Golang test harness. Distributed systems is usually the missing piece for a backend engineer, and if you can say (and if you actually have) that you've implemented Raft using Go channels, people will take you seriously when it comes to interviewing etc.</p></pre>Kistamushken: <pre><p>Thank you, very useful :) </p></pre>govision: <pre><p>I'm sorta in the same boat but doing only front end :/
I'm trying to build a site but idk wether to use a 3rd party package or not. Seems like there are more resources on non 3rd party package code then packaged ones. But then you have to fight the http core package way of implementing the 3rd party packages.</p>
<p>One thing that took me a while was the whole cors thing with cross origins stuff for restful API.</p>
<p>Here's some of my resources I've been updating as I go along. May not be the "right" way but it's learning.</p>
<p><a href="https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk" rel="nofollow">https://docs.google.com/document/d/1Zb9GCWPKeEJ4Dyn2TkT-O3wJ8AFc-IMxZzTugNCjr-8/edit?usp=drivesdk</a></p></pre>jonbonazza: <pre><p>Also, FWIW, when I am interviewing candidates for a job, I am less interested in what they already <em>know</em> (though don't get me wrong, this is certainly important to some degree as well), and more interested in their aptitude to <em>learn</em>. I find that it is much more enjoyable and easier to work with people who are not caught up in their ways based on past experiences, and are instead willing to keep an open mind. Also, cultural fit is a <em>HUGE</em> requirement for any candidates that I interview. I'm in the gaming industry, but since we don't actually write games, but instead work on a major service, we get a lot of the benefits of the game industry, without much of the downsides (i.e crunching). Because of this, we get <em>a lot</em> of candidates that are trying to migrate from a career in gameplay or engine programming, and into back end development. We, of course, don't expect these people to know everything there is to systems engineering, but we expect them to be competent programmers with a high aptitude for learning. As long as they have these two traits, we will usually at least give them a shot to convince us to hire them. In fact, most of my current team has come from some other form of development. I came from full stack, personally, while others were game developers, engine developers, front-end developers, and even a couple Ops people.</p></pre>gutigen: <pre><p><a href="https://github.com/avelino/awesome-go" rel="nofollow">https://github.com/avelino/awesome-go</a></p></pre>tech_tuna: <pre><p>Just GO for it. . .</p>
<p>OK, I'm done for the day.</p></pre>zackkitzmiller: <pre><p>How tied are you to go only, and where are you based?</p></pre>Kistamushken: <pre><p>I am based in Stockholm, Sweden. Not tied at all. I do acknowledge, that "only Go" stack is somewhat exotic, that's why I am asking more about ecosystem I should look into, rather than the language itself. </p>
<p>Language can be picked in a week or two(well, maybe not C++ or some hardcore functional stuff).</p></pre>natefinch: <pre><p>try to find a job where they're doing android development but are also looking for backend help. Most apps need servers. Offer your app expertise with the condition that you get to tag along with the server team and come up to speed that way.</p>
<p>Honestly, having someone that spans teams is super useful, in my experience, because they can more easily understand how both sides work, and help explain to the backend engineers why they shouldn't just rip out that API, and explain to the app engineers why they shouldn't request the same data 10 times in 2 seconds... (etc)</p></pre>kd7nyq: <pre><p>People are saying that "oh, picking up a language is easy." I would tend to agree; being able to write compiling applications is easy. The biggest stumbling block that I see among Go programmers is that they fail to understand that Go is the result of conscious efforts to make a language that is concise, simple, and powerful. Rob Pike and Ken Thompson are on the project, and they've experienced nearly all of programing history. They and their team have carefully crafted Go to enable people to write concise, simple, and powerful programs. The part that you need to understand is that people seem to have an overwhelming need to make it complicated. Yes, you can write Java code in Go, with piles of frameworks and lots of unnecessary abstractions. The language was developed explicitly to eliminate those, though. Make it simple. To make it simple, though, you need to understand the history, context, and details of the language. I urge you to watch the tech talks and presentations produced by the Go team. Rob Pike and Andrew Gerrard are two good names to search for on YouTube.</p></pre>
