3 ms·

I agree. Specialists are really just full stack engineers who haven't fulfilled their potential. Why hire a self-proclaimed UX guy? Unless I have all the amazin

by alttab 14y ago

I agree. Specialists are really just full stack engineers who haven't fulfilled their potential. Why hire a self-proclaimed UX guy? Unless I have all the amazing engineers I need for my team (99% not the case), I'm looking for someone who can do multiple things. The best ones are ones that can do schema design, query design, system and model architecture, front-end wireframes, javascript, and implementation. That said, your comment about the front end being "tightly woven in with the business logic of the module" scares me a little. The front end is presentation and interaction. Unless most of your businesses mojo is client side, even a full stack engineer should design each layer as fully cohesive and encapsulated components. I may have misunderstood you, however.

sreyaNotfilc 14y ago
What I mean by "tightly woven" is that you know exactly what values/components/types need to communicate with each other whether its the front end or the back end. You're not wasting time trying to match a spec sheet or fulfill a precondition to an existing back-end procedure (cause honestly those things just don't fit right in). That is, you're not spending time trying to put a square peg into a round hole.
- alttab 14y ago
  Ah I getcha now. I think my point is still valid though - and in fact full stack engineers are more likely to write a spaghetti code mess from the back to the front because they control the entire feature and may see the code in its entirety as one "feature" and thus one code base.
  - sreyaNotfilc 14y ago
    You are valid. I wrote a whole post about this but the reply didn't seem to work so I lost the full reply. I did write most of my ideas to "underwater"'s comment. Basically, my position is more on the fact that if you need things done quickly, then a full stack guy is the one you need. You can fix/abstract the code later. In fact, I encourage that. But to get the ball rolling, you're gonna need some quick and useful (sometimes ugly spaghetti) code. Its a trade off that must be made, especially you're rapidly building your product.

by alttab 14y ago

sreyaNotfilc 14y ago

What I mean by "tightly woven" is that you know exactly what values/components/types need to communicate with each other whether its the front end or the back end. You're not wasting time trying to match a spec sheet or fulfill a precondition to an existing back-end procedure (cause honestly those things just don't fit right in). That is, you're not spending time trying to put a square peg into a round hole.

alttab 14y ago
Ah I getcha now. I think my point is still valid though - and in fact full stack engineers are more likely to write a spaghetti code mess from the back to the front because they control the entire feature and may see the code in its entirety as one "feature" and thus one code base.
- sreyaNotfilc 14y ago
  You are valid. I wrote a whole post about this but the reply didn't seem to work so I lost the full reply. I did write most of my ideas to "underwater"'s comment. Basically, my position is more on the fact that if you need things done quickly, then a full stack guy is the one you need. You can fix/abstract the code later. In fact, I encourage that. But to get the ball rolling, you're gonna need some quick and useful (sometimes ugly spaghetti) code. Its a trade off that must be made, especially you're rapidly building your product.