Some thoughts I had about how the ease of computing, along with the complexity of online accounts and setups are making it really difficult for the next generation to understand what's going on.
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.
Couldn't comment on the blog itself, but Gmail simply uses Google Closure and its compiler to get minified Javascript + DOM.
And it so happens that Closure code tends to create a ton of extra DOM structure within the JS code, so the 50-level-deep <div> tree isn't much of a surprise, especially with something as complex as the Gmail UI.
Right - what I'm saying is that it's okay to be slightly more verbose if it means added readability. My point was that it was the comb. of 4 libraries that's causing a lot of context switching on the same line of code.
Great advice! I have the feeling that comm., like you say, is the most important aspect and something that just doesn't come naturally for a lot of engineers. Sometimes a simple email or ping can alleviate days of frustration and head-wall smashing, but I know personally I can do a much better job and perhaps it's a prereq to be noticed as "management material".
Being passionate isn't a substitute for mastery, getting burned out by hard work, and general marketability of an idea or product. No matter now passionate you might be about widget-building, your lack of skill and the lack of a market for widgets is the cold hard reality.
Hm, it's not really an Apples-to-Apples comparison, b/c all the 27" 2560px displays I can think of are IPS, while 1080p's in the sub-$300 range are TN's. You'd be paying for the added display quality on top of the bigger screen + resolution.
For dev work, I'd say the nicest thing about the 27"s is the ability to put two full pages side-by-side, either a browser window + IDE, or vert. split IDE code panes. 1920px isn't quite there for two panes of code.
And personally, I've had 2+ 24"s, and I've actually found it too cumbersome: having emails/IM's on a second window actually becomes distracting, and moving your mouse cursor across so many pixels was less precise than either alt-tabbing to the right program or switching spaces/virtual desktops w/ a keyboard shortcut. For me anyway, 27" is the sweet spot.
Speaking as a UC Berkeley grad w/ many coworkers who weren't from UCB/Stanford (which is common in SV companies), having the school on your resume makes it easier to get noticed from recruiters, but it's just one of many factors considered to "get in the door".
I've seen more companies look for other publicly visible areas of code output:
- Github/Stack Overflow/Quora
- Blogs/social sites like HN, reddit at times
- Open source projects
Internships or experience at well-regarded companies also helps a lot, and once you get through one of these avenues it's easier to keep the ball rolling and get introductions to the hot companies in our industry.
Of course, you still have to pass the interview, regardless of which university you studied in. =)