I agree with the Learn An Additional Language section, but I would add: people should learn the most used language on the other side of the fence. By that I mean there are really no true "full stack" people out there (people tend to specialize in one area or the other), but it's always good to know a bit about the other side. If you're FE developer, learn enough Java, Python, Ruby, etc to be able to make your own changes in tickets (with review from a BE developer of course). If you're a BE developer, learn Javascript, HTML, CSS to the point of being able to make your own changes (again, with review from your FE person, if you have one). You'll learn to create better solutions to projects people outside the tech team will make to you if you have a better idea of the full picture.
Agreed. I even have a great anecdote to illustrate this.
I worked with a team that was split into front and back-end. The team was building an SPA, so the back-end team built out a REST API to compliment the front-end SPA framework. Unfortunately, the API data naming conventions were-designed-like-this.
Those poor front-end developers had to keep switching between dot notation and key notation to access the state props, depending on if it was one word or multiples. A little more insight and understanding into the javascript language would give you the foresight to spare the front-end developers what is essentially a soul crushing way to write javascript.
I agree with the Learn An Additional Language section, but I would add: people should learn the most used language on the other side of the fence. By that I mean there are really no true "full stack" people out there (people tend to specialize in one area or the other), but it's always good to know a bit about the other side. If you're FE developer, learn enough Java, Python, Ruby, etc to be able to make your own changes in tickets (with review from a BE developer of course). If you're a BE developer, learn Javascript, HTML, CSS to the point of being able to make your own changes (again, with review from your FE person, if you have one). You'll learn to create better solutions to projects people outside the tech team will make to you if you have a better idea of the full picture.
Agreed. I even have a great anecdote to illustrate this.
I worked with a team that was split into front and back-end. The team was building an SPA, so the back-end team built out a REST API to compliment the front-end SPA framework. Unfortunately, the API data naming conventions were-designed-like-this.
Those poor front-end developers had to keep switching between dot notation and key notation to access the state props, depending on if it was one word or multiples. A little more insight and understanding into the javascript language would give you the foresight to spare the front-end developers what is essentially a soul crushing way to write javascript.
Perhaps a little melodramatic, but still =D
Those on the front-end could use only bracket notation which wouldn't pose any problems for them . Dosen't seem to be much of a problem to me ??
Yeah, it's not really a big problem. Just a good illustration.