4 ms·

This may be my favorite quote... "Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between. If they

This may be my favorite quote... "Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between. If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on. Same for Architect help. But in general, expectation is that engineers will handle everything they need themselves." I actually like this idea. Building my own website as well as working as the senior engineer during my day job forces me to be involved in all facets of web developing. The jobs are not abstracted. You are expected to know what you're doing from the front end to the back end. If not, nothing get done in a timely manner. I like this method because the front end is tightly woven in with the business logic of the module that you're working on. In other words, you know what the code is doing inside and out.

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.
polyfractal 14y ago
Eh, I dunno. I don't want the carpenter designing my house, and I don't want the architect cutting the main support beams. I want both of them doing what they do best, and working together to do it.
- wpietri 14y ago
  I think that's a false dichotomy. The good carpenters I know are all reasonably good designers. And I would never hire an architect who didn't have some experience actually making things; otherwise there's too much risk of getting what software people call "architecture astronauts". I think the right solution is the approach IDEO takes: teams of what they call T-shaped people: broad general understanding, with great depth in a particular area. In Facebook's case in particular, I don't think they need a lot of brilliant design as much as they need solid, competent, well-integrated features. Indeed, their latest attempt at design brilliance, Timeline, has been much less well executed than their zillion engineer-led evolutionary changes.
  - jbl 14y ago
    The IDEO approach is something that I like and look for in the people I work with. When I was teaching I grad school, I'd often exhort my students to think at least one level 'above' and one level 'below' whatever phenomena we were studying that week. With software, I think it's important to see the forest for the trees, so that you can make the best tree for the forest... (apologies for the tortured analogy)
crazygringo 14y ago
I dunno. I personally am a full-stack guy. But when I work with back-end developers who don't know MySQL inside and out, and they write a query that works fast in development but slow in production because they didn't realize the column index they specified won't work because of a string collation incompatibility between tables, and they've never even heard of this kind of problem before... Then I wish they'd stick to writing their back-end executable code, and have a database guy write their query for them, and have a JavaScript expert take care of the front-end stuff. It's not a question of intelligence, just a question of experience. You have to have done a lot of JavaScript coding to realize never to call parseInt(x), but always parseInt(x, 10), for example. And the number of CSS incompatibilities between browsers that you need to account for... Unless someone has a lot of full-stack experience, it doesn't seem that great that they should be pushing out full-stack code on their own at a place like Facebook. Maybe code reviews will catch those kinds of things, though.
- sreyaNotfilc 14y ago
  My point is that sometimes you don't have the luxury of having x amount of DB people and x amount of js folks and x amount of server side guys and so on and so forth. I'm coming from a place with very low resources (I'm the only developer at my job right now, we use to have 4). (I wrote this stuff before but for some reason it just didn't go through) As far as testing wise and building things, I believe it is best to have an engineer that is able to fulfill those roles for the following reasons... 1) They understand the structures and what it is that makes an application do what it does. 2) Its a very good learn tool. If you mess up you know exactly why. You'll be able to constantly adapt yourself to become better. 3) Waiting for your "role" to be utilized within an organization may sound great because you have free time, but it causes stagnation and "Diva-ism". That is the whole "Its not my job, so I don't care about your problem" or "You need me more than I need you" attitude. 4) You can move relatively quickly since the code and logic is coming directly from you. Yes, specialists are very important. For large organizations they are very needed. But, to get things to work right now, you need to be flexible and open-minded. Look at Facebook's UI, its not the prettiest (blue bar at the top and 3 columns), yet its an extremely popular product. Most users just want the damn thing to work. I'm no web designer, but I understand that a clean UI is needed. I'm not a DB guy, but I can figure out most problems. Etc. etc. I think that's what Zuck actually wants in his engineers. Guys and gals that can see a problem and fix it on their own. Guys and gals that can think of a cool idea, test it, and have it released for that 1%. Code reviews and peer help will smooth things out. I believe it was Jamie Zawinski's interview in the book "Coders at Work" that had the same mantra when he developed Netscape. Just get the thing out fast. You'll get more eyes on it. And you can always make it better the next time around. It seems like a lot of shops do that. Its a cut throat world and if you spend too much time trying to be super clean and precise, you'll still be on version 1 while your competitor is on version 10.

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.

polyfractal 14y ago

Eh, I dunno. I don't want the carpenter designing my house, and I don't want the architect cutting the main support beams. I want both of them doing what they do best, and working together to do it.

wpietri 14y ago
I think that's a false dichotomy. The good carpenters I know are all reasonably good designers. And I would never hire an architect who didn't have some experience actually making things; otherwise there's too much risk of getting what software people call "architecture astronauts". I think the right solution is the approach IDEO takes: teams of what they call T-shaped people: broad general understanding, with great depth in a particular area. In Facebook's case in particular, I don't think they need a lot of brilliant design as much as they need solid, competent, well-integrated features. Indeed, their latest attempt at design brilliance, Timeline, has been much less well executed than their zillion engineer-led evolutionary changes.
- jbl 14y ago
  The IDEO approach is something that I like and look for in the people I work with. When I was teaching I grad school, I'd often exhort my students to think at least one level 'above' and one level 'below' whatever phenomena we were studying that week. With software, I think it's important to see the forest for the trees, so that you can make the best tree for the forest... (apologies for the tortured analogy)

crazygringo 14y ago

I dunno. I personally am a full-stack guy. But when I work with back-end developers who don't know MySQL inside and out, and they write a query that works fast in development but slow in production because they didn't realize the column index they specified won't work because of a string collation incompatibility between tables, and they've never even heard of this kind of problem before... Then I wish they'd stick to writing their back-end executable code, and have a database guy write their query for them, and have a JavaScript expert take care of the front-end stuff. It's not a question of intelligence, just a question of experience. You have to have done a lot of JavaScript coding to realize never to call parseInt(x), but always parseInt(x, 10), for example. And the number of CSS incompatibilities between browsers that you need to account for... Unless someone has a lot of full-stack experience, it doesn't seem that great that they should be pushing out full-stack code on their own at a place like Facebook. Maybe code reviews will catch those kinds of things, though.

sreyaNotfilc 14y ago
My point is that sometimes you don't have the luxury of having x amount of DB people and x amount of js folks and x amount of server side guys and so on and so forth. I'm coming from a place with very low resources (I'm the only developer at my job right now, we use to have 4). (I wrote this stuff before but for some reason it just didn't go through) As far as testing wise and building things, I believe it is best to have an engineer that is able to fulfill those roles for the following reasons... 1) They understand the structures and what it is that makes an application do what it does. 2) Its a very good learn tool. If you mess up you know exactly why. You'll be able to constantly adapt yourself to become better. 3) Waiting for your "role" to be utilized within an organization may sound great because you have free time, but it causes stagnation and "Diva-ism". That is the whole "Its not my job, so I don't care about your problem" or "You need me more than I need you" attitude. 4) You can move relatively quickly since the code and logic is coming directly from you. Yes, specialists are very important. For large organizations they are very needed. But, to get things to work right now, you need to be flexible and open-minded. Look at Facebook's UI, its not the prettiest (blue bar at the top and 3 columns), yet its an extremely popular product. Most users just want the damn thing to work. I'm no web designer, but I understand that a clean UI is needed. I'm not a DB guy, but I can figure out most problems. Etc. etc. I think that's what Zuck actually wants in his engineers. Guys and gals that can see a problem and fix it on their own. Guys and gals that can think of a cool idea, test it, and have it released for that 1%. Code reviews and peer help will smooth things out. I believe it was Jamie Zawinski's interview in the book "Coders at Work" that had the same mantra when he developed Netscape. Just get the thing out fast. You'll get more eyes on it. And you can always make it better the next time around. It seems like a lot of shops do that. Its a cut throat world and if you spend too much time trying to be super clean and precise, you'll still be on version 1 while your competitor is on version 10.