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.
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.01.14 |
∞
Very solid mini intro to Git by Tobias Gunther over at A List Apart. You can find this content virtually anywhere by running a simple Google search, but Tobias makes a stronger case. First he succinctly lays out the reasons why Git is such an improvement over older repository systems like Subversion. There’s also some great use of visuals here to lay out what happens during core commands like ‘git reset’ and ‘git revert’.
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.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.
09.12.14 |
∞
Another few months, another Sublime Text icon replacement. This one, put together by designer Rafael Conde, is really gorgeous in its simplicity and subtle grid pattern. And Rafael mentions in the Dribbble comments, it flows especially well with stock icons in OS X Yosemite.
09.10.14 |
∞
I’ve traditionally been a big fan of the Meslo web fonts for coding, a variant of Apple’s ultra-popular Menlo. But that all changed when I discovered Input, a new set of fonts optimized for programming by Font Bureau. The glyphs and overall layout is gorgeous.
They offer a sans, serif, and monospaced version (I run with the default Input Mono set) and best of all, it’s free for private use.
08.01.14 |
∞
I’ve documented best practices in the Git version control system for my coworkers often, from meetings to random Google Docs and emails. Yet reading over this post by developer Jean-Philippe Boily, I realize he’s eloquently and succinctly gone through the key principles that matter most. Worth a read for Git newbies.
04.23.14 |
∞
Tech student Tim Green put together a pretty slick set of features and shortcuts for GitHub and Git I’ve rarely seen elsewhere. Some of the command line Git tricks were my favorites; I had no idea you could style git status with the ‘-sb’ modifier or trivially jump to the previous Git branch with a wildcard symbol.
04.12.14 |
∞
I had a fun time using Dayle Rees’s color schemes in Sublime Text a month ago. But lately I’ve been using this alternative color scheme that’s a touch less colorful than Rees’s yet works beautifully for my coding style. Its got an interesting theme as well, but I found it a bit too spaced out for my tastes (I pair the color scheme with Flatland.) By designer Jaime Wilson.