01.14.15 |
∞
The Tomorrow Lab’s Derek Johnson writes one of the smartest pieces I’ve read on why sudden interruptions (or last minute, poorly planned meetings) can wreck such havoc on a developer’s workflow:
Developers don’t wear headphones because we enjoy music more than anyone else, it’s because headphones shut everything out and give us the mental space we need to build a very complicated model…
…If you’re an interrupter and you get a terser response than you might have expected please don’t take it personally. We’re just aware of the model starting to loosen at the more precarious points and are getting frantic about the need to get back at work.
12.06.14 |
∞
Writer Shawn Blanc on smart custom perspectives in Omnifocus:
In short, you should create your own custom perspective for “Today”. And let that list show you all the tasks which are either Due today or which are Flagged. When you are doing your daily review and scrubbing your list, don’t think about what’s due — because it should already be given a proper due date — instead, just flag the tasks you want to get done that day. Then, go to your Today perspective and now you’ve got a list of items which are both urgent (i.e. due today) and important (i.e. flagged).
Bingo. When I started using Omnifocus, virtually everything had a strict due date, which became maddening after time. When everything is “due”, it’s hard to manage what is really important. Overall, be less aggressive with real due dates unless it’s really due.
10.14.14 |
Work |
∞
What defines an experienced web developer in 2014? Looking back on my own progress, I transitioned from entry level to senior roles and became “experienced”. Yet it was surprising to reflect on what skills and traits led me to that point.
Some experience stems from core programming knowledge: familiarity with HTML, CSS, and JavaScript syntax, along with optimization techniques for each language. And given how fast the web changes, experience can imply some web frameworks mastery. Today, popular examples include MVC frameworks (Angular, Ember), web components (Polymer) and responsive grid patterns (Foundation, Susy).
Programming chops also contribute; practically any position requires a baseline technical aptitude to sustain a team’s momentum. Yet as my career has gone on, I’ve found three traits outside of tech that usually separate the experienced from the entry level: wisdom, communication and “T-shaped” skills.
Wisdom is experience defined by long-term development cycles. It’s working through projects over months or years. For solo, agency and freelance developers, it’s defining a long term relationship with one or more clients for an extended period. Developers with high wisdom levels know how to work with other tech personnel. They quickly assess their team’s strengths, weaknesses, and who’s best to delegate for different aspects of the job. They also give assured estimates and know how to best integrate their tech skills into a larger team.
Communication centers on verbal and written skills. Part of that is back and forth with the rest of the tech team through succinct bug tickets and clear project status reports. And on most front end development projects, tight communication with the designers and project managers is essential. In addition, business staff often notice and gravitate towards developers with strong speaking and presentation skills, regardless of their technical aptitude.
T-shaped skills aren’t directly related to web development yet are helpful for the overall company. Aesthetic design, UX, analytics, marketing and business are common examples. T-shape skills are especially important for front end web developers, as they are often faced with many client-facing micro decisions due to lack of time or definition from other groups. For example, there may be a high fidelity spec for a new page design, but a few elements don’t quite match, so the developer adjusts some spacing and padding. Or a new web app is launching and a developer realizes select user actions aren’t being captured by analytics; he or she makes a quick correction. Many of these details aren’t noticed until well after a product is shipped but can have a cumulative benefit for users.
All three of these attributes have one thing in common: there’s rarely shortcuts. It takes time, earned from months and years of work within a team. When you run through an entire dev project cycle – tech assistance to early design iterations, developing a feature set, fixing QA bugs and launching the product – there’s invaluable knowledge gained that can’t be gleamed from a blog post or weekend workshop. Admittedly, some developers are naturally gifted communicators and are equipped with a T-shaped skill base by the time they reach their first web gig. Yet having worked with a large variety of web developers in my career, that’s rare.
So, some advice to those starting out: it’s ok to take a break from learning the hottest web framework to brush up on your speaking and writing skills. It’s also smart to ask questions and have interests in the rest of your business. And if you get the chance to work with well-respected, senior developers, do so. Be patient and take in everything you can. Experience takes time.
10.13.14 |
∞
Engineer Pete Warden:
We’re still behaving like the rebel alliance, but now we’re the Empire. We got where we are by ignoring outsiders and believing in ourselves even when nobody else would. The decades have proved that our way was largely right and the critics were wrong, so our habit of not listening has become deeply entrenched. It even became a bit of a bonding ritual to attack critics of the culture because they usually didn’t understand what we were doing beyond a surface level.
09.23.14 |
∞
Developer Michael Church writes about the difficulties a friend of his has at getting a senior development job:
This whole issue is about more than what one knows and doesn’t know about technology. As programmers, we’re used to picking up new skills. It’s something we’re good at (even if penny-shaving businessmen hate the idea of training us). This is all about social status, and why status is so fucking important when one is playing the work game– far more important than being loyal or competent or dedicated.
Low and high status aren’t about being liked or disliked. Some people are liked but have low status, and some people are disliked but retain high status. In general, it’s more useful and important to have high status at work than to be well-liked. It’s obviously best to have both, but well-liked low-status people get crap projects and never advance. Disliked high-status people, at worst, get severance.
Michael’s main argument is that the overwhelming majority of those who remain software engineers – even those that are highly talented – can never can crack out of a low social status. Very interesting and depressing nonetheless.
09.22.14 |
∞
Like many other developers and designers out there, almost every day I make the rounds of Designer News, Hacker News along with occasional forays into Sidebar and Dribbble.
Usually that involves a lot of Safari tabs and context switching. Panda aims to change that: it’s a simple, well designed web app that puts many of these popular sites side by side. As a Chrome extension, it can be the default state of any new tabs you create. There’s a few minor customization issues that keep me from diving fully in but it’s worth a look.
09.19.14 |
∞
Anthony Colangelo, writing for A List Apart:
When you hear the word “just” being thrown around, dig deep into that statement and find all of the assumptions made within it. Zoom out and think slow.
Your product lives and dies by the decisions discovered between ideation and creation, so don’t just put it up on a server somewhere.
08.04.14 |
∞
Facebook engineer Carlos Bueno, writing a post already heavily passed around tech circles about the Valley/startup insular culture:
The problem is that Silicon Valley has gone completely to the other extreme. We’ve created a make-believe cult of objective meritocracy, a pseudo-scientific mythos to obscure and reinforce the belief that only people who look and talk like us are worth noticing. After making such a show of burning down the bad old rules of business, the new ones we’ve created seem pretty similar.
It’s been over a month since this was published, but Carlos’ post struck a cord with me and is worth revisiting. I suspect it’s going to be one of those posts that I revisit from time to time long from now, especially as I reach more positions to hire and shape the culture of a company.
07.30.14 |
Work |
∞
I usually give my students and junior developers two pieces of advice: practice your skills and work on strong side projects. Practice is a given, but projects on your own time are a greatly underrated and often forgotten asset.
Strong projects challenge you in at least one way. If you’re focusing on development, maybe you’ll target a framework or an aspect of a programming language you haven’t used yet. If you’re a designer, it could be a new tool or workflow. Remember, the side project needs elements of the familiar to make regular progress so you do not get frustrated and give up, yet remain achievable over time.
Great side projects are a mix of what you can execute quickly but are also somewhat foreign and difficult. It’s a twist on your existing point of view, not one that’s completely coming from left field. One personal example: a refresh of this very site (familiar), but undertaken with a fresh set of responsive design tools and Sass underpinning the styling (foreign).
It’s not an accident I generated my latest project after work hours; the best side projects are almost always outside the day job. Because you’re free from work interference, it can and should move at your own pace. It’s ok to be disorganized too. You don’t even have to finish; the project can flounder and die days, weeks or months down line. As long as you grow from it, it’s still a success. And above all, side projects should be fun.
Shouldn’t a good job nullify the need for side projects? Not exactly. Even with the best jobs, your personal growth goals are never perfectly aligned with the company you work for. And some work, even with the best intentions, can get stuck in a boring, repetitive rut. A strong side project provides an opportunity to escape that.
At the very least, even a so-so side project teaches you something new on your own timetable. And at its best, side projects can establish your “niche” as a designer or developer, a critical way to stand out from your tech peers. They did for me; three years at Gucci, my first formalized web job, pushed me most of the way. However, it’s my Hacker News and Rdio browser extensions on my own time, along with some minimal Tumblr themes, that confirmed my interests as a web developer on the very front of front-end development that often drifts into UX and aesthetic design.
Good jobs push your career far. Good side projects push it further. Make time and a commitment to both.
07.29.14 |
∞
Developer Mark Llobrera over at A List Apart gives advice for successfully integrating new web design and development techniques on new projects:
Look at the projects you have on the horizon. Think about the portions of your workflow that you want to improve, and pick just one of those things to introduce into your project. Why just one? It allows you enough space to experiment without endangering your project.
A mentor of mine once told me that programming (and especially programming for the web) boils down to reducing the number of “unknowns” on a project to a manageable number. One is fine, two is a stretch, and three is asking for trouble. If you think exploring HTML/CSS wireframes could have a positive impact on your work, introduce just that one thing. Most projects have enough built-in friction without adding or changing multiple processes at the same time.