11 ms·

> The complicated web was here. [...] > I've given in my resignation at my current place of employment and will be seeking an exclusively back-end role for my

> The complicated web was here. [...] > I've given in my resignation at my current place of employment and will be seeking an exclusively back-end role for my next adventure Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend. Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests, honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have upgraded their crypto libraries to fight against (insert bad guy here). The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway. The complicated web is everywhere. Retreating to the backend is no escape. Sorry.

sriku 6y ago
Some of my colleagues and I were joking recently that the "AWS well architected" framework should've been named "AWS well paid" framework. It's like it's no longer legit to run a small site serving a small community. It has to "scale", be secure against minions who want to usurp your machines, have backups, CI, CD, GitHub events, run on K8sa and be "cloud native", and on and on .. to show some HTML page when an end point is hit. I feel I can't even joke about this any more here. The stacks run deep on both ends .. but I'm often not sure to what end.
- dvfjsdhgfv 6y ago
  It's basically about money. As a tech guy, you choose the technologies with the largest margin. Companies who use AWS are either (1) rich enough to spend huge sums of money, (2) can't calculate or are gullible enough to believe it's the best solution for them. In either case, typically you're more likely to make money on AWS-related technologies than working for more cost-conscious clients who understand the cost structure of the overall infrastructure. That's why people code a Hello World as a React app on AWS, as ridiculous as it may seem.
  - matthewmacleod 6y ago
    This is absolute nonsense which reveals more about your ignorance of companies’ technology trade offs than it does anything else. Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.
    - collyw 6y ago
      My guess is that > 90% of people using Kubernetes will never need to scale elastically. My company uses it, cost a ton of developer time. It gives us high availability which is nice, but we have no need for the scaling in the foreseeable future, and that was what was used to sell Kubernetes to our founders.
      - Guthur 6y ago
        Yes, though the GP made no reference to Kubes at all and was talking more generally about AWS. AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
      - nilkn 6y ago
        I see this sentiment a lot online, but k8s for us has been quite simple to learn and use and, like you acknowledged here, solved a lot of availability issues out of the box for us that we previously had to deal with in more manual ways. Better yet, it’s a standardized platform that we can use company-wide and that every engineer understands, including potential hires — that’s very valuable. I feel it has become a common trope to claim k8s is complicated and overkill but we are quite glad we made the move to using it.
        weeboid 6y ago
        Have you ever considered the workforce aspect of technologies? Like, you'll still need devops, and if you aren't at least dabbling in containers and elasticity, you're going to get the luddites.
- j45 6y ago
  Linux has far fewer networking and scaling issues as it once had, something that cloud helped with. VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.
- vmception 6y ago
  It actually doesn't have to. Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there. But its scalable enough!
  - busterarm 6y ago
    I built a static site served by S3 & cheap Lightsail boxes that serves a $5B/yr business. That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
    - Railsify 6y ago
      This use case is about where AWS cost effective scalability ends, anything more complicated and you are into multiple thousands a month for a redundant solution for a critical web-app with a database. We used to run prod and stage envs in aws but as our stage environment grew we realized we could on-prem some pretty bad-a* hardware for the cost of a few months AWS billing. Now we run prod on aws, staging and dev locally.
      - murukesh_s 6y ago
        Second that.. and hardest thing is you don't really know where you are getting charged. i mean you can look at the billing but boy they do add up to 1000s before you know and you are so hooked into auto scaling, s3, rds with multi-az what not..
      - monsieurbanana 6y ago
        There's a cost maintaining a staging environment on-prem while prod is on a cloud. Slightly different versions of databases, different networking, etc... It could create issues. This does depend on how much you buy into the AWS ecosystem, if it's strictly EC2-only it's not as much of a problem. Not that I wouldn't do it, a lot of times it does make financial sense.
      - 6y ago
durnygbur 6y ago
I have a strong impression also that the hysteria accomodated well in the backend world. Folks in the workplace need containers on k8s cluster to deploy a static website. I feel I'll start throwing things on hearing the word "cluster", but wait - the data lakes on the cloud are coming. We need a bloody thunderstorm.
- alpaca128 6y ago
  Theory: data lake Reality: data leak I'm also tired of all those hyped technologies. Sure, containers, "serverless" etc. are neat and powerful things, but in most cases it reminds me of Top Gear's kitchen blender powered by a V8 engine. Yes, I could use TypeScript, React and a couple other libraries to build that website. But then I also need to handle 3 configuration files and their interactions, wait for the incremental compilation to run through after every change, waste time debugging because the incremental builds got the whole amalgamation into an undefined state and deploying the project now requires its own toolchain and scripts.
  - bryanrasmussen 6y ago
    >it reminds me of Top Gear's kitchen blender powered by a V8 engine. sadly, there is no kitchen blender powered by Node.js in the V8 engine.
    - BoumTAC 6y ago
      coming soon to Deno !
      - tanseydavid 6y ago
        418 I'm a teapot
rzzzt 6y ago
This fine song includes the name of 168 AWS services: https://youtu.be/BtJAsvJOlhM https://youtu.be/BtJAsvJOlhM
- mellosouls 6y ago
  Brilliant! Tom Lehrer would approve I reckon.
vmception 6y ago
> The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. That reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in
collyw 6y ago
The thing is a LAMP stack would serve most businesses needs fine and would take a fraction of the effort to implement. Server side rendering and a bit of jQuery. Actually matching technology to requirements is going to make me unemployable in the future.
higerordermap 6y ago
Assuming learning is not a big problem, which area would be pleasurable experience? There's not a whole lot there except Back end, front end, embedded, mobile application, ML? Any substantial fields I missed?
- splatcollision 6y ago
  Game development! You can choose whatever tech you are most familiar with and you get to be creative, work on probably the most interdisciplinary area of technology possible.
  - Kaze404 6y ago
    How do you start with game dev as someone who already knows programming? I've tried to get into it at least 3 different times with different approaches, and could never reach a point where I could make even the most basic of games after hours of Unity articles / Unity projects / YouTube videos / Godot documentation, whatever. Every time I try I feel like I must be missing something because everyone says it's easy to get into, but all the information I can find is completely useless.
    - sprkwd 6y ago
      Make a game in the programming language that you know.
    - why_Mr_Anderson 6y ago
      Because game dev isn't about programming for the most part, making game engines is. But that's a whole different beast where hardcore math and all kind of tricks and hacks often considered 'wrong|unmaintainable|bad practices' here on HN rule supreme.
    - Viliam1234 6y ago
      Big frameworks like Unity make difficult things easier, but easy things more complicated. I would recommend starting with a simple game, in the programming language you are most fluent with. An example of a simple game would be a minesweeper. An example of a complicated game would be a massive online multiplayer strategic 3D shooter with artificial intelligence... in Unity ;) Computer games have a few things different than usual applications; you probably don't want to encounter all those differences in your first project. The user interface is generally completely different: instead of dialogs with buttons and input fields, you typically have one window with canvas, where you paint things. (If you also want buttons and input fields, you probably have to implement them yourself on top of that.) Things are in motion, they appear and disappear, interact with each other. You probably want to clearly separate updating of the game state from displaying the game state. (You probably also want to save and load the game state.) In addition to algorihms, there is lot of data: design of the levels, different units which are kinda the same thing but with different parameters and different pictures. (Will you also make a level editor? Or design a clever system for easily describing the level in a plain-text file?) Plus the details that still require lot of work, like the intro screen, help screen, option screen, high score table, etc. Plus you sometimes need to care about performance; a one-second delay to e.g. calculate the proper path through a maze may be unacceptable, because it would make the game freeze for a moment every time you command a unit to go somewhere. For network games, performance is even more complicated. You need to make semi-arbitrary choices about object dimensions, bitmap resolutions, etc. For a professional looking game, you also need music and sound effects. None of this is rocket science. But each of these things requires some thinking and experimenting, when you do them for the first time. You might want to create a demo for each of them separately. Definitely don't use all of them in your very first game. Start with a simple game, such as minesweeper. Open a game dialog with a canvas. Load bitmaps from resource files. Place the mines randomly in a memory array, then paint that information on the canvas. When user clicks mouse, convert the mouse coordinates to the click field, update the memory array accordingly, then repaint the canvas. That's all, but you need to think about all possible game states: each field can be "hidden", "hidden with mark", "hidden with question mark", "open", "open with number", "open with a bomb that killed you". Also, when you are killed, you cannot click anymore (other than the restart button). As a next game, just make a simple animated demo: balls bouncing within a rectangle. (To keep it simple, balls only bounce from the boundaries of the rectangle, not from each other.) Your game state is where the balls are (x, y) and what is their speed (sx, sy). You need a method that will update the state when some times has passed; the time interval is provided as a parameter. The coordinates need to be floats, even if ultimately they will be rounded to int when you paint the balls. A linear movement is simple: add "time × sx" to "x"; if you passed a boundary, fix "x" and flip the sign on "sx" (and do the same for "y" and "sy".) Make a loop that waits for some time interval, updates the state, and repaints the state. Congratulation, you made your first animation! Now try supporting the mouse; when a user clicks find out if any ball was clicked, if yes, change its color. When you have these two parts mastered, you are ready to make a simple animated game. On a very abstract level, there is a game state, a method that updates the game state when a time interval has passed, a method that updates the state when a mouse was clicked or a key was pressed, and a method that paints the state. And an infinite loop of: wait, update for time, update for mouse and key events, repaint; and again. For a more complex game, the game state is more complex, but the essence remains. (Plus you may want a method to save the state to a file, and load the state from a file.) Moving a player character can be done the same way. You have an object with coordinates "x", "y" and speed "sx", "sy". When time passes, "x" and "y" update based on "sx" and "sy". (To implement friction, make also "sx" and "sy" move slowly towards zero based on time passed. To implement gravity, increase "sy" based on time passed.) When an arrow key is pressed, "sx" or "sy" is either increased or decreased. When the object hits an obstacle, it bounces. When the player object overlaps another object (a collectible item, or a missile), the other object is destroyed and the game state is updated accordingly (score increased, key collected, or hit points reduced). How to implement shooting? The shots are also objects with their own "x" "y" "sx" "sy", which are generated when you press a key, and disappear when they hit something or get out of the screen. How to implement enemies? For starters, make them bounce off the boundaries of the screen, and shoot at random moment in a random direction. Check when your missile collides with an enemy (destroy the missile, reduce enemy hit points, destroy enemy if hit points get to zero), check when enemy missiles collide with you. The next step would be to load levels from files. For example, imagine a rectangular maze M×N, loaded from a text file (where walls are represented by "x" characters, and empty squares by spaces), and your task is to walk from the start to finish. Optionally, add colored keys and doors (specified in the text file e.g. as "a" "b" "c" for keys, and "A" "B" "C" for doors), where you need to collect a key in order to be able to walk through the corresponding door. Make 10 levels like this; completing a level starts the next level. The easy way is to do this without animation: your positions are integers in the maze grid, and they update only when you press a key. Now make the same version, but more alive. Make a rectangular maze with walls loaded from file. Make yourself and the enemies bounce from the walls (this will require a little math, but quite simple). Add shooting. (To keep it simple, enemies do not bounce from each other. Neither do you bounce from an enemy, but your collision removes hit points from both.) Now all you need is to add more sophisticated behavior to the enemies. The constraints are that the enemy has a state, and the method that updates the state of the game will also update the enemy state. (The algorithm for enemy is implemented in small pieces. For example, instead of a loop "choose a random place on the screen, walk there", you would specify small increments, such as "if you have a place chosen, move towards it time×sx steps; if you reached the place, choose another"... essentially write a code which executed many times repeatedly will produce the desired behavior, but at each time only does a tiny part of it.) Make multiple enemies, specified in a configuration file: they will differ by bitmaps, amount of hitpoints, and maximum speed. ...and when this is done, you are ready for Unity. What Unity does for you is providing 3D graphics and 3D physics (it will calculate the bouncing and collisions for you).
uxcolumbo 6y ago
> The endless bullshit of dealing with "Log in with Facebook/Google/Apple" Do you have some sources for that? Just curious. I personally avoid having to login via FB, Google etc.
Nic0 6y ago
> Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend. I was thinking exactly the same thing while reading the conclusion of the post. You leave frontend complexity for even more complexity, are you nuts! The good old single PHP page is gone long time ago as well.
sai_c 6y ago
Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests, honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have upgraded their crypto libraries to fight against (insert bad guy here). The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway. I've often heard the term "If bridges were built like software..." to show the fragility and ad hoc building of software. But let's image "If bridges were built like software" to survive pretty much any kind of malicious attack (like in "WTF? Why did the bridge collapse when those crazy guys bombed it?"). So maybe, just maybe, not everything should be a web app, and be connected to everything. EDIT: Corrected typo.
justsomeuser 6y ago
> the story's exactly the same on the backend I don't think it is, for the business-logic code portion any way. For backend, the hiring is typically "you know Java" or whichever $backend_language. For frontend, your job application will be terminated in the early stages of the pipeline because you do not know the latest 2 year old framework (that is written in JS that you know extremely well). 10 years of JS and web experience amounts to nothing because "you do not know Angular". I do not think this applies to backend at all, they just see a "langauge-X developer".
- sai_c 6y ago
  I don't think it is, for the business-logic code portion any way. You gotta be joking. Most of the time this is an attempt to transform dysfunctional processes from reality, to functional processes in software, resulting in dysfunctional software.
codegeek 6y ago
This person backends. No seriously though, well said :). If the author thinks backend is all sane, let us welcome them to the world of everything you said plus more stuff. How about working with databases, ORM, API (is there a standard ?), package managers (composer?, gem?), authentication/authorization ? (should I use JWT..ooh thats crazy. cookies anyone??) etc etc
simonbarker87 6y ago
Yes, as a full stack dev I think the front end is easier than backend. We joked at my old place that the best thing for a web dev's sanity long term is to retire into SQL
FriedrichN 6y ago
Neither is retreating to B2B. Personally I can deal with B2B than with B2C because it's not all about The New Shiny Thing™. But then you get to integrate with some weird funky SAP extension some company wrote and they can't even configure their web service URLs right. If you work in IT, you'll have to perpetually fight against people and technology. It's why people hate people who work in IT, because they always say "no".
deleted 6y ago
[deleted]
kgwxd 6y ago
At a larger company, most of that would be in the infrastructure department.
- draw_down 6y ago
  And the same is true for frontend.
properdine 6y ago
My impression is that backend changes more slowly (and is easier to control) than frontend. At least when you're doing backend you can choose your whole stack (vs. frontend where you have to deal with a huge array of different types of computers and such). Plus IMO you set up your framework for building once or twice and just reuse it everywhere, so doesn't end up as difficult as the faster changing front end work.
ezekg 6y ago
> But the story's exactly the same on the backend. Kubernetes. Docker. AWS and its gazillion impenetrable product names. Not in my experience. I made the switch from front-end to back-end about 5 years ago and I never worked with k8s or AWS, and Docker very little only for spinning up local envs; those were always the job for devops. I guess it just depends on the company. I mainly read code and wrote code.
jaeming 6y ago
What's funny to me is that whenever I get stuck with docker or docker-compose (or getting our various docker services talking to each other), I'm told by a certain engineer that I ask for help from, "It's really not that complicated.". Then a week later he's asking me for help setting up eslint and vscode auto-correct/format, telling me he's been trying to get it working half the day, emphasizing how terrible JS tooling is. I of course sent him on his way with a working set-up five minutes later. I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.
- bluefirebrand 6y ago
  This illustrates really nicely how the "Full Stack Developer" is becoming more and more impossible to be. It's not enough to know how to set up a couple of servers with routing and IP blacklisting and load-balancing, you have to build a mountain of microservices with an even bigger mountain of tools. For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else. It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.
  - dimitrios1 6y ago
    I've just come back to standard web architecture these days. Just use Rails, Laravel, or Phoenix. While your compatriots will still be configuring their prettierrc and eslint, you'll have released your first set of features.
    - bluefirebrand 6y ago
      Yeah. It's fine for personal projects or small things but good luck convincing a big company that what they really need is 2009 technology nowadays.
specialist 6y ago
I sympathize differently: I just want to work. Change for change's sake gets really, really old. In 2007, I was already long past done. DHTML [1997] and AJAX [1999] were distant memories. (Had to check wiki.) I mercifully forget what the hotness was during the final years of the Bush Admin. Sure, some things get better. Fonts on the web are now pretty terrific. But React? Please kill me. Components? Code generation? Meta meta languages? Ya, no thanks. But I am happy the kids are now finally rediscovering (reinventing) server side includes. Full circle. Good times.
- collyw 6y ago
  I think once you have been working in tech for a decade or so, you start to see the fashion show for what it is. Constant churn for the sake of it. Sure some stuff is genuinely useful, but the majority of it gets forgotten about pretty quickly.
antfarm 6y ago
Native iOS is relatively simple toolwise, esp. with Swift and SwiftUI, yet at the same time very deep and powerful.

sriku 6y ago

Some of my colleagues and I were joking recently that the "AWS well architected" framework should've been named "AWS well paid" framework. It's like it's no longer legit to run a small site serving a small community. It has to "scale", be secure against minions who want to usurp your machines, have backups, CI, CD, GitHub events, run on K8sa and be "cloud native", and on and on .. to show some HTML page when an end point is hit. I feel I can't even joke about this any more here. The stacks run deep on both ends .. but I'm often not sure to what end.

dvfjsdhgfv 6y ago
It's basically about money. As a tech guy, you choose the technologies with the largest margin. Companies who use AWS are either (1) rich enough to spend huge sums of money, (2) can't calculate or are gullible enough to believe it's the best solution for them. In either case, typically you're more likely to make money on AWS-related technologies than working for more cost-conscious clients who understand the cost structure of the overall infrastructure. That's why people code a Hello World as a React app on AWS, as ridiculous as it may seem.
- matthewmacleod 6y ago
  This is absolute nonsense which reveals more about your ignorance of companies’ technology trade offs than it does anything else. Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.
  - collyw 6y ago
    My guess is that > 90% of people using Kubernetes will never need to scale elastically. My company uses it, cost a ton of developer time. It gives us high availability which is nice, but we have no need for the scaling in the foreseeable future, and that was what was used to sell Kubernetes to our founders.
    - Guthur 6y ago
      Yes, though the GP made no reference to Kubes at all and was talking more generally about AWS. AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
    - nilkn 6y ago
      I see this sentiment a lot online, but k8s for us has been quite simple to learn and use and, like you acknowledged here, solved a lot of availability issues out of the box for us that we previously had to deal with in more manual ways. Better yet, it’s a standardized platform that we can use company-wide and that every engineer understands, including potential hires — that’s very valuable. I feel it has become a common trope to claim k8s is complicated and overkill but we are quite glad we made the move to using it.
      - weeboid 6y ago
        Have you ever considered the workforce aspect of technologies? Like, you'll still need devops, and if you aren't at least dabbling in containers and elasticity, you're going to get the luddites.
j45 6y ago
Linux has far fewer networking and scaling issues as it once had, something that cloud helped with. VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.
vmception 6y ago
It actually doesn't have to. Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there. But its scalable enough!
- busterarm 6y ago
  I built a static site served by S3 & cheap Lightsail boxes that serves a $5B/yr business. That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
  - Railsify 6y ago
    This use case is about where AWS cost effective scalability ends, anything more complicated and you are into multiple thousands a month for a redundant solution for a critical web-app with a database. We used to run prod and stage envs in aws but as our stage environment grew we realized we could on-prem some pretty bad-a* hardware for the cost of a few months AWS billing. Now we run prod on aws, staging and dev locally.
    - murukesh_s 6y ago
      Second that.. and hardest thing is you don't really know where you are getting charged. i mean you can look at the billing but boy they do add up to 1000s before you know and you are so hooked into auto scaling, s3, rds with multi-az what not..
    - monsieurbanana 6y ago
      There's a cost maintaining a staging environment on-prem while prod is on a cloud. Slightly different versions of databases, different networking, etc... It could create issues. This does depend on how much you buy into the AWS ecosystem, if it's strictly EC2-only it's not as much of a problem. Not that I wouldn't do it, a lot of times it does make financial sense.
    - 6y ago

durnygbur 6y ago

I have a strong impression also that the hysteria accomodated well in the backend world. Folks in the workplace need containers on k8s cluster to deploy a static website. I feel I'll start throwing things on hearing the word "cluster", but wait - the data lakes on the cloud are coming. We need a bloody thunderstorm.

alpaca128 6y ago
Theory: data lake Reality: data leak I'm also tired of all those hyped technologies. Sure, containers, "serverless" etc. are neat and powerful things, but in most cases it reminds me of Top Gear's kitchen blender powered by a V8 engine. Yes, I could use TypeScript, React and a couple other libraries to build that website. But then I also need to handle 3 configuration files and their interactions, wait for the incremental compilation to run through after every change, waste time debugging because the incremental builds got the whole amalgamation into an undefined state and deploying the project now requires its own toolchain and scripts.
- bryanrasmussen 6y ago
  >it reminds me of Top Gear's kitchen blender powered by a V8 engine. sadly, there is no kitchen blender powered by Node.js in the V8 engine.
  - BoumTAC 6y ago
    coming soon to Deno !
    - tanseydavid 6y ago
      418 I'm a teapot

rzzzt 6y ago

This fine song includes the name of 168 AWS services: https://youtu.be/BtJAsvJOlhM https://youtu.be/BtJAsvJOlhM

mellosouls 6y ago
Brilliant! Tom Lehrer would approve I reckon.

vmception 6y ago

> The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. That reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in

collyw 6y ago

The thing is a LAMP stack would serve most businesses needs fine and would take a fraction of the effort to implement. Server side rendering and a bit of jQuery. Actually matching technology to requirements is going to make me unemployable in the future.

higerordermap 6y ago

Assuming learning is not a big problem, which area would be pleasurable experience? There's not a whole lot there except Back end, front end, embedded, mobile application, ML? Any substantial fields I missed?

splatcollision 6y ago
Game development! You can choose whatever tech you are most familiar with and you get to be creative, work on probably the most interdisciplinary area of technology possible.
- Kaze404 6y ago
  How do you start with game dev as someone who already knows programming? I've tried to get into it at least 3 different times with different approaches, and could never reach a point where I could make even the most basic of games after hours of Unity articles / Unity projects / YouTube videos / Godot documentation, whatever. Every time I try I feel like I must be missing something because everyone says it's easy to get into, but all the information I can find is completely useless.
  - sprkwd 6y ago
    Make a game in the programming language that you know.
  - why_Mr_Anderson 6y ago
    Because game dev isn't about programming for the most part, making game engines is. But that's a whole different beast where hardcore math and all kind of tricks and hacks often considered 'wrong|unmaintainable|bad practices' here on HN rule supreme.
  - Viliam1234 6y ago
    Big frameworks like Unity make difficult things easier, but easy things more complicated. I would recommend starting with a simple game, in the programming language you are most fluent with. An example of a simple game would be a minesweeper. An example of a complicated game would be a massive online multiplayer strategic 3D shooter with artificial intelligence... in Unity ;) Computer games have a few things different than usual applications; you probably don't want to encounter all those differences in your first project. The user interface is generally completely different: instead of dialogs with buttons and input fields, you typically have one window with canvas, where you paint things. (If you also want buttons and input fields, you probably have to implement them yourself on top of that.) Things are in motion, they appear and disappear, interact with each other. You probably want to clearly separate updating of the game state from displaying the game state. (You probably also want to save and load the game state.) In addition to algorihms, there is lot of data: design of the levels, different units which are kinda the same thing but with different parameters and different pictures. (Will you also make a level editor? Or design a clever system for easily describing the level in a plain-text file?) Plus the details that still require lot of work, like the intro screen, help screen, option screen, high score table, etc. Plus you sometimes need to care about performance; a one-second delay to e.g. calculate the proper path through a maze may be unacceptable, because it would make the game freeze for a moment every time you command a unit to go somewhere. For network games, performance is even more complicated. You need to make semi-arbitrary choices about object dimensions, bitmap resolutions, etc. For a professional looking game, you also need music and sound effects. None of this is rocket science. But each of these things requires some thinking and experimenting, when you do them for the first time. You might want to create a demo for each of them separately. Definitely don't use all of them in your very first game. Start with a simple game, such as minesweeper. Open a game dialog with a canvas. Load bitmaps from resource files. Place the mines randomly in a memory array, then paint that information on the canvas. When user clicks mouse, convert the mouse coordinates to the click field, update the memory array accordingly, then repaint the canvas. That's all, but you need to think about all possible game states: each field can be "hidden", "hidden with mark", "hidden with question mark", "open", "open with number", "open with a bomb that killed you". Also, when you are killed, you cannot click anymore (other than the restart button). As a next game, just make a simple animated demo: balls bouncing within a rectangle. (To keep it simple, balls only bounce from the boundaries of the rectangle, not from each other.) Your game state is where the balls are (x, y) and what is their speed (sx, sy). You need a method that will update the state when some times has passed; the time interval is provided as a parameter. The coordinates need to be floats, even if ultimately they will be rounded to int when you paint the balls. A linear movement is simple: add "time × sx" to "x"; if you passed a boundary, fix "x" and flip the sign on "sx" (and do the same for "y" and "sy".) Make a loop that waits for some time interval, updates the state, and repaints the state. Congratulation, you made your first animation! Now try supporting the mouse; when a user clicks find out if any ball was clicked, if yes, change its color. When you have these two parts mastered, you are ready to make a simple animated game. On a very abstract level, there is a game state, a method that updates the game state when a time interval has passed, a method that updates the state when a mouse was clicked or a key was pressed, and a method that paints the state. And an infinite loop of: wait, update for time, update for mouse and key events, repaint; and again. For a more complex game, the game state is more complex, but the essence remains. (Plus you may want a method to save the state to a file, and load the state from a file.) Moving a player character can be done the same way. You have an object with coordinates "x", "y" and speed "sx", "sy". When time passes, "x" and "y" update based on "sx" and "sy". (To implement friction, make also "sx" and "sy" move slowly towards zero based on time passed. To implement gravity, increase "sy" based on time passed.) When an arrow key is pressed, "sx" or "sy" is either increased or decreased. When the object hits an obstacle, it bounces. When the player object overlaps another object (a collectible item, or a missile), the other object is destroyed and the game state is updated accordingly (score increased, key collected, or hit points reduced). How to implement shooting? The shots are also objects with their own "x" "y" "sx" "sy", which are generated when you press a key, and disappear when they hit something or get out of the screen. How to implement enemies? For starters, make them bounce off the boundaries of the screen, and shoot at random moment in a random direction. Check when your missile collides with an enemy (destroy the missile, reduce enemy hit points, destroy enemy if hit points get to zero), check when enemy missiles collide with you. The next step would be to load levels from files. For example, imagine a rectangular maze M×N, loaded from a text file (where walls are represented by "x" characters, and empty squares by spaces), and your task is to walk from the start to finish. Optionally, add colored keys and doors (specified in the text file e.g. as "a" "b" "c" for keys, and "A" "B" "C" for doors), where you need to collect a key in order to be able to walk through the corresponding door. Make 10 levels like this; completing a level starts the next level. The easy way is to do this without animation: your positions are integers in the maze grid, and they update only when you press a key. Now make the same version, but more alive. Make a rectangular maze with walls loaded from file. Make yourself and the enemies bounce from the walls (this will require a little math, but quite simple). Add shooting. (To keep it simple, enemies do not bounce from each other. Neither do you bounce from an enemy, but your collision removes hit points from both.) Now all you need is to add more sophisticated behavior to the enemies. The constraints are that the enemy has a state, and the method that updates the state of the game will also update the enemy state. (The algorithm for enemy is implemented in small pieces. For example, instead of a loop "choose a random place on the screen, walk there", you would specify small increments, such as "if you have a place chosen, move towards it time×sx steps; if you reached the place, choose another"... essentially write a code which executed many times repeatedly will produce the desired behavior, but at each time only does a tiny part of it.) Make multiple enemies, specified in a configuration file: they will differ by bitmaps, amount of hitpoints, and maximum speed. ...and when this is done, you are ready for Unity. What Unity does for you is providing 3D graphics and 3D physics (it will calculate the bouncing and collisions for you).

uxcolumbo 6y ago

> The endless bullshit of dealing with "Log in with Facebook/Google/Apple" Do you have some sources for that? Just curious. I personally avoid having to login via FB, Google etc.

Nic0 6y ago

> Oh boy. I sympathise entirely with this post, but the story's exactly the same on the backend. I was thinking exactly the same thing while reading the conclusion of the post. You leave frontend complexity for even more complexity, are you nuts! The good old single PHP page is gone long time ago as well.

sai_c 6y ago

Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests, honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have upgraded their crypto libraries to fight against (insert bad guy here). The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway. I've often heard the term "If bridges were built like software..." to show the fragility and ad hoc building of software. But let's image "If bridges were built like software" to survive pretty much any kind of malicious attack (like in "WTF? Why did the bridge collapse when those crazy guys bombed it?"). So maybe, just maybe, not everything should be a web app, and be connected to everything. EDIT: Corrected typo.

justsomeuser 6y ago

> the story's exactly the same on the backend I don't think it is, for the business-logic code portion any way. For backend, the hiring is typically "you know Java" or whichever $backend_language. For frontend, your job application will be terminated in the early stages of the pipeline because you do not know the latest 2 year old framework (that is written in JS that you know extremely well). 10 years of JS and web experience amounts to nothing because "you do not know Angular". I do not think this applies to backend at all, they just see a "langauge-X developer".

sai_c 6y ago
I don't think it is, for the business-logic code portion any way. You gotta be joking. Most of the time this is an attempt to transform dysfunctional processes from reality, to functional processes in software, resulting in dysfunctional software.

codegeek 6y ago

This person backends. No seriously though, well said :). If the author thinks backend is all sane, let us welcome them to the world of everything you said plus more stuff. How about working with databases, ORM, API (is there a standard ?), package managers (composer?, gem?), authentication/authorization ? (should I use JWT..ooh thats crazy. cookies anyone??) etc etc

simonbarker87 6y ago

Yes, as a full stack dev I think the front end is easier than backend. We joked at my old place that the best thing for a web dev's sanity long term is to retire into SQL

FriedrichN 6y ago

Neither is retreating to B2B. Personally I can deal with B2B than with B2C because it's not all about The New Shiny Thing™. But then you get to integrate with some weird funky SAP extension some company wrote and they can't even configure their web service URLs right. If you work in IT, you'll have to perpetually fight against people and technology. It's why people hate people who work in IT, because they always say "no".

deleted 6y ago

[deleted]

kgwxd 6y ago

At a larger company, most of that would be in the infrastructure department.

draw_down 6y ago
And the same is true for frontend.

properdine 6y ago

My impression is that backend changes more slowly (and is easier to control) than frontend. At least when you're doing backend you can choose your whole stack (vs. frontend where you have to deal with a huge array of different types of computers and such). Plus IMO you set up your framework for building once or twice and just reuse it everywhere, so doesn't end up as difficult as the faster changing front end work.

ezekg 6y ago

> But the story's exactly the same on the backend. Kubernetes. Docker. AWS and its gazillion impenetrable product names. Not in my experience. I made the switch from front-end to back-end about 5 years ago and I never worked with k8s or AWS, and Docker very little only for spinning up local envs; those were always the job for devops. I guess it just depends on the company. I mainly read code and wrote code.

jaeming 6y ago

What's funny to me is that whenever I get stuck with docker or docker-compose (or getting our various docker services talking to each other), I'm told by a certain engineer that I ask for help from, "It's really not that complicated.". Then a week later he's asking me for help setting up eslint and vscode auto-correct/format, telling me he's been trying to get it working half the day, emphasizing how terrible JS tooling is. I of course sent him on his way with a working set-up five minutes later. I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.

bluefirebrand 6y ago
This illustrates really nicely how the "Full Stack Developer" is becoming more and more impossible to be. It's not enough to know how to set up a couple of servers with routing and IP blacklisting and load-balancing, you have to build a mountain of microservices with an even bigger mountain of tools. For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else. It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.
- dimitrios1 6y ago
  I've just come back to standard web architecture these days. Just use Rails, Laravel, or Phoenix. While your compatriots will still be configuring their prettierrc and eslint, you'll have released your first set of features.
  - bluefirebrand 6y ago
    Yeah. It's fine for personal projects or small things but good luck convincing a big company that what they really need is 2009 technology nowadays.

specialist 6y ago

I sympathize differently: I just want to work. Change for change's sake gets really, really old. In 2007, I was already long past done. DHTML [1997] and AJAX [1999] were distant memories. (Had to check wiki.) I mercifully forget what the hotness was during the final years of the Bush Admin. Sure, some things get better. Fonts on the web are now pretty terrific. But React? Please kill me. Components? Code generation? Meta meta languages? Ya, no thanks. But I am happy the kids are now finally rediscovering (reinventing) server side includes. Full circle. Good times.

collyw 6y ago
I think once you have been working in tech for a decade or so, you start to see the fashion show for what it is. Constant churn for the sake of it. Sure some stuff is genuinely useful, but the majority of it gets forgotten about pretty quickly.

antfarm 6y ago

Native iOS is relatively simple toolwise, esp. with Swift and SwiftUI, yet at the same time very deep and powerful.