allenc

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.

Careful consideration is losing out to parabolic progress.

Migrating my blog from WordPress → Ghost, made easier with a bit of Claude-assisted vibe scripting.

https://allenc.com/ -- My blog, mostly on eng. management topics plus other personal interests, occasionally submitted on HN.

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.

Nothing worthwhile is ever easy. =)

As someone who does a lot of interviews and has switched jobs six months ago, I understand how it feels, on both sides. I've written my fair amount on the topics too (http://allenc.com/2011/04/how-to-score-a-google-onsite-inter... and http://corner.squareup.com/2011/10/why-we-pair-interview.htm...).

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".

Somebody else has already went through the same idea and over the course of months thoroughly denounced its viability:

http://calnewport.com/blog/

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. =)

Then just say that, and leave the rest of the suggestions on creating a product, finding a market, etc. out of it. It's like the tired old "if you get x people for y a day" or "if you could only get [arbitrary small percentage] of a [giant market]" marketing speak that any semi-experienced dev knows is completely misleading.

There are devs struggling to make a few hundred sales in the iOS/Android app stores while producing quality products. Selling software isn't easy, and making it sound trivial well...makes it sound like a scam.

Wow, is this a troll/joke post? This is why developers look at marketers with such disdain...

Yea, maybe "intangibles" was a bad choice of wording - what I meant was more along the lines of "unquantifiable", in the sense that it's not just more options or salary or maybe 401k matching. Branding and title would fit well along those lines.

Mmm...I personally see a distinction between front-end developer and front-end engineer. What you're describing sounds like a FE dev.

A FE Eng. is still a software engineer, which means you ought to be able to pick up any backend language, be it Python, Rails, PHP, or a Java/C++ service. A lot of the time you'd be tasked with bugs/features that require a lot of FE work, and some backend work as well; it's so much more efficient for you to just write the backend handlers, esp. when it's usually a stone's throw away from an ORM layer or a simple SQL call.

I'd also consider knowing something about UI/UX to be a nice bonus. In reality, your UI designer isn't going to provide mocks for every page and every interaction; you're going to have to fill in the gaps, and probably do so without a huge dropoff in quality. At the same time, I usually find myself bringing another perspective from the UI side when talking w/ the designer, and since most places only have one UI guy it's valuable for them to get feedback, even if it's from someone not at the same level.

Like learning how to program, I think it's a mistake to look at a finished product, go "I want my project to look like that!" and then try to deconstruct the end result systematically.

I'd suggest forgetting the "oh pretty!" aspect of design, and just focus on simplicity, both on aesthetics (What's simpler than a line to separate? White space!) and usability (Simpler than two clicks: one click). The basic principles of fonts, spacing, and color theory always apply, so start with getting comfortable with these techniques. The gradients, subtle shading, and translucency effects can come later and build on top of the basics anyway.

Eh, I can't draw myself, so I probably can't comment on good logo design. I think as long as it's clean and distinctive - branding your app - it should work well. You can always hire a designer to redo it when you gain some traction.

Right. The general idea is: the bigger the font size, the more people will notice it, so make the irrelevant stuff small and the attention-grabbing stuff big. As to colors, I just saw something someone else posted that can help you develop a coherent color scheme:

http://www.techiemania.com/5-awesome-free-tools-to-help-you-...

And another article with good design pointers submitted to HN:

http://www.visualmess.com/

As to the logo, the same ideas apply: more whitespace between the title, tagline and "beta", vary the font faces to provide contrast, and try using contrasting primary colors to make it a bit more dynamic.

Some things just from a design and aesthetics standpoint:

- More white space. It's the easiest way to lose the "cluttered" feel of having giant blocks of explanatory text.

- Vary the fonts and font sizes. In particular, your nav. bar's font sizes are too big and distract from the section titles; you can lose the nav altogether for a landing page.

- Have a consistent coloring scheme. Pick 2-3 colors (maybe the ones from your logo) and stick with them: one color for the titles, one for links, one for text. E.g., using light purple for your secondary title text at the bottom makes them look like links.

- Make the "sign up" button stand out more. That's your call to action, and right now it blends in with the background.

Agreed, although some laxer languages - say, Javascript - will let you do it all the same. Like I said, it's not necessarily a rule to follow, but whenever I come across people who would do things slightly off (from common coding practices anyway) I notice the difference, and if it's something I recognize I put a little mark there in case they're really, really close. I come from a C++ background, so stuff like i++ and ++i really do make a diff.

Hm, I think Fermi problems are not as much in style, but certain interviewers still ask them from time to time.

I'm thinking more about just annoying puzzle problems with one right answer, that if you don't have an "aha!" moment you'd probably never get (and remember, this is in the context of a stressful interview). Stuff like the Two Glass Balls problem:

http://sites.google.com/site/mytechnicalcollection/puzzle/tw...