You're also more likely to move between clients, so something is less-than-ideal you're not there as long. But they still know the difference, and they often organize their own teams. You can still end up doing staff augmentation with the exact same aforementioned non-software companies. Look for companies whose primary purpose is to deliver software, as they're way better at it than companies who do other stuff and, by the way, they need some IT people to make stuff.Īlso, try companies that provide consulting. Where do we find these teams who do "real" agile and write unit tests and refactor stuff? The rest of the time, both before and after, I was asking the same question. The result is that we rapidly developed one of the most useful features I'd worked on in years. On the last project I worked on we even had more than the usual input into what the intent of the feature was and how it should behave. Sometimes they would ask me to rearrange the elements a little or add different classes. Then I'd take a stab at adding class names to the HTML elements which he or she would use to add styles. I asked, "Hey, instead of me formatting this whole thing with CSS and doing it wrong, and then you having to undo everything, what if I just output raw, unstyled HTML, and you added the CSS?" It was like that because we made it that way. That was a very rare case (in my experience) of effective self-organization. But if I did the whole thing myself it would look like the front of that horse. I didn't become a JavaScript rock star but I wrote good, maintainable code. Pushing more on the front end improved my skills. We'd collaborate a lot on the front end, tweaking the HTML and behavior. Then, right at the point where it came time to apply CSS I'd hand it off to people who were really good at it. The most fun I had was on a team where I would develop everything from the backend database and services to the front-end rendering and JavaScript. I see it more as making fun of what happens when the industry invents a useless, meaningless label and then pressures developers to identify with it. What I instantly saw is that someone knows how to draw an entire horse, but they're much better at drawing one part of it than at drawing the other. In other words, if there is an offense, who is the offended party? I was looking for the part where you say that you or one of your friends is a full stack developer, but didn't see it. You didn't explain why you take it personally. Go Home: 4 Techniques That Help You Leave Work At Work If you liked this article, consider reading: What do you think? Has your company pushed too hard for split UI/Backend teams? Have they pushed too hard for full stack teams? Are there other ways to keep collaboration and empathy high? Let’s just work on the API and the UI together. I don’t want to wait 2 weeks for the backend developer to get back to me with a new API so I can finally start my UI task. And I’m accepting the fact that I’ve been burnt by teams before that were not truly operating like a team. it’s that you shouldn’t cast judgement on your emotions- you should accept them. And if I’ve learned anything from the Buddhist scholars that I use as research for this blog. I know that I shouldn’t be so bothered by this but I am. Each person will always have their strengths and weaknesses, but together the team should be fully autonomous and productive. Modern web development is pushing hard for “full stack teams” not “full stack devs.” If there was an image like that of me, it would be a horse with mostly the ribs and the abdomen shaded in. people can help out in a pinch (if needed).better estimates since everyone has passing familiarity with each layer of the stack.I think the best rationale for a “full stack dev” is that the healthiest teams are full of empathetic people who are willing to put themselves in the shoes of any member of their team (regardless of where they specialize) so they can learn about the challenges of their teammates. I’d prefer that managers and leads invert their thinking or at least open up to the notion of a happy, autonomous team. Listen, our users don’t care about our architecture, they care about the code working end-to-end. All too often, managers stand behind tired ideas like “there is no full stack developer” and then force team structures that prevent good, quick conversations. It’s a funny meme, but we need less walls and more bridges. I’d also take a “partial stack” dev if they are curious (described below). Personally, I would take that meme image in a heartbeat. If you were building a team, would you rather have that meme image above, or a developer who only knows one part of the system? The meme above could potentially be casting shade on “full stack devs” by depicting them as a drawing of a horse but where only the backend is drawn out.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |