Yea, I chat with ex-colleagues about their work and how they're faring since we've worked together.
I'm a director of eng. as well, so there'll be times when I reconnect with former managers and reports and provide/get mentorship that way as well. The key is to actually keep in contact and in touch beyond any singular job; if you were able to mentor them while you shared an office, that relationship is still valuable afterwards. Of course, this means that you have to develop the skill & reputation to be a good mentor to others around your job.
People management & leadership | San Francisco | Allen | http://allenc.com
I've been a software eng. manager for a couple of years now, currently a director of engineering at a mid-sized fintech company. I've always mentored other managers within the companies I worked in, but I'm realizing there's plenty folks who move into mgmt. for the first time w/o much support, and even a chat or two goes a long ways to making the role transition less daunting.
Hi, I'm the lead Square Dashboard engineer at Square, and the one who wrote that blog post a year ago on building our app in Ember and D3.
I'll say that after a year's worth of experience with Ember, we've gotten much better at it, but we've still had to add our own components (e.g., a validation framework) or fork off what components and use + fix them before they're completely production ready. We accepted these tasks as a cost of living on the bleeding edge, but admittedly given the rapid pace that the API has changed in the past year, we've acculumated a bit of necessary tech debt.
W.r.t. Ember Data, that wasn't a consideration for us, as the component didn't exist when we were building Dashboard. That said, we chose to integrate with ED in one of our more recent features, and while I'd be lying if I said there weren't any pain, what we took away were learnings about how our non-ED models related to each other and informed subsequent refactors that made the overall app better.
Ah, thanks - I guess I should just get rid of the fixed header...
But to your first point, I don't think it's just learning HTML and CSS syntax. For example, I've never seen a SE break out XScope and measure the exact pixels between two elements, obsess about the opacity of a drop shadow, or spend a few hours to tweak the bezier curve of an animation. It's like saying that SEs will just struggle with design initially.
I'd argue in theory, no, but in practice this is often helpful.
For example, I was working on a multi-step activation system where I had to get the user in a certain state no a specific UI element showed up. That required spending 5-10 min. every time to set up that user, which would go away once you use that button, and development would have taken days.
That is, until someone showed me what the Activation schema + model looked like and how to just toggle the boolean or attach an expected relation. You could maybe argue that there should be an admin interface for manipulating model state, but nobody else really would need it: BE devs can already change the models, and business types don't care about this particular state of the user.
Yea, my fault; I had written something more inflammatory, but after a bunch of edits I had moderated my tone once I realized I was just ranting against bad FE candidates I had interviewed.
Yea, sorry - thought about adding a simple lightbox, but most of our posts on that blog don't have any images. The full-size img is there, just right click and "open image in a new tab".
Nah, that was something doctored up by a designer. Don't think you can get that without doing some manual popup window manipulation, which is really ugly in its own right.
I think a part of it is ego, especially nowadays - some really good engineers are doing their own startups now, and when these companies start hiring they're looking for people just as good as they are, which means taking a page out of the Google/Facebook style interview process. I've met and worked with people who, while with great intentions, think great software engineering comes from graduate-level CS studies.
That said, resumes and achievements aren't great indicators of success because so many people have good-looking job histories and many can also sound good just talking about their experience. For me, front-end web eng. has become a pain to hire for; too many candidates put down things they don't know enough about, and unless they have fully-viewable source online it's hard to tell whether they accomplished much of anything in their past projects.
I do think our current standard of heavy whiteboard interviews is misleading, though, which is why I prefer pairing interviews when given a choice. Working with an engineer is a great way to measure cultural fit.
And finally, companies are super careful with filling a position because while firing someone is at-will, the cost in bringing that person up-to-speed, dealing with the bad player's code and work, the messiness in letting that person go (in planning, morale, etc.), not to mention salary and severance make everybody err on the side of caution.
I'm a director of eng. as well, so there'll be times when I reconnect with former managers and reports and provide/get mentorship that way as well. The key is to actually keep in contact and in touch beyond any singular job; if you were able to mentor them while you shared an office, that relationship is still valuable afterwards. Of course, this means that you have to develop the skill & reputation to be a good mentor to others around your job.