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.
