Updates from May, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • Collin Anderson 2:50 pm on May 30, 2016 Permalink | Reply  

    The Quiet Crisis unfolding in Software Development 

    Be Wary of High Performers – Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally.

    Encourage Continual Product Improvement – Improve the database schema even if it hurts in the short term. Delete old and unused code…..continual improvement gives them autonomy and a strong sense of making valuable contributions on their own terms. Don’t underestimate the morale boost.

    Encourage Code Ownership. – Management likes to reduce risk by treating developers as interchangeable… all developers being expected to be familiar with all areas of the code. That minimizes the pain when any individual developer leaves the team or the company. This is false economy. Your employees like working for you — right? — which means turnover should be low. …giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.

    Recognize Leaders – Getting back into the zone takes time. Expect your leaders to take more time to complete their projects — after all, they’re doing two jobs.

    Watch Out for Misleading Metrics – Software developers aren’t stupid and some of them will quickly learn how to game the system if counterproductive incentives are visible.

    Limit Interruptions – Encourage your team to prefer communication in roughly the following order so that interruptions are minimized: e-mail, chat room (if your team isn’t using a chat room yet, they should be), instant message, phone call/dropping by in person.

    Prefer Private Workspaces – Audible and visual distractions should be minimized which means at a minimum each developer should have a cubicle with high cube walls and a small entrance

    Encourage Experimentation – Software developers are not devoid of good ideas and have the in-the-trenches experience to have good instincts about how applications may be improved and extended.

    Let Employees Leave – Forcing employees to remain in your group can never lead anywhere good. It’ll impact their morale which impacts the morale of the entire group. It’s also likely they’ll become less effective and in extreme circumstances simply leave the company.

    Never Turn Down Small Requests – Unless they have a constant stream of requests that never seems to end you should never say no with only one exception: if you believe the entire team will then want the same small request and it really will impact the budget too much. … When compared to their salary and benefits these little requests go a long way toward keeping morale and thus productivity high and they cost peanuts.

    Abolish Yearly and Bi-Yearly Performance Reviews – Your employees should never wait six to twelve months to discover what you feel they’ve excelled at and what they need to work on. Communication between managers and employees should be like a river that never stops flowing.

    You’re Not Better than Your Employees – Just because your employees report to you doesn’t imply you’re somehow smarter or better.

    Don’t Discount Younger or Older Developers

    Don’t have Stupid Dress Codes

    View story at Medium.com

  • Collin Anderson 9:02 am on April 26, 2016 Permalink | Reply  

    Desirable developer skills 

    Desirable developer skills:

    1 Ability to ignore new tools and technologies
    2 Taste for simplicity
    3 Good code deletion skills
    4 Humility

  • Collin Anderson 8:59 pm on April 1, 2016 Permalink | Reply  

    You Aren’t Gonna Need to Design It 

    A short tale of building what matters and skipping the rest.


    In cases like this, you can either anticipate all the likely possibilities and build lots of things to insure yourself against potentially bad situations, or you can ship what you’ve got, wing it, and be prepared to make changes as you go.

    As is our style, we ran with the latter…and it was completely fine! Most people leave our original email quoted below when they reply. Then we click the Unsubscribe link for them. That’s it. It’s lo-fi and works in 99% of cases. If the quoted email isn’t there, Tom programmatically unsubscribes the person by hand. We have to do that a couple of times per week. No biggie at all.

    So this is YAGNI in practice. You might be familiar with YAGNI as a programming-specific concept, but I think it’s just as applicable—if not more so!—on the design side.

    Design is often a matter of diving headfirst into an unknown abyss, and preparing to modify your thinking based on what you learn. When you’re doing that, there’s no sense in trying to protect yourself from bumps along the way.

  • Collin Anderson 3:01 pm on March 30, 2016 Permalink | Reply  

    Native ubuntu on windows. 

    Totally crazy.


  • Collin Anderson 8:07 pm on March 23, 2016 Permalink | Reply  

    NPM & left-pad: Have We Forgotten How To Program? 

    Strive For Few Dependencies

    Every package that you use adds yet another dependency to your project. Dependencies, by their very name, are things you need in order for your code to function. The more dependencies you take on, the more points of failure you have. Not to mention the more chance for error: have you vetted any of the programmers who have written these functions that you depend on daily?

    NPM & left-pad: Have We Forgotten How To Program?

  • Collin Anderson 9:29 am on March 18, 2016 Permalink | Reply  

    Frameworks don’t make much sense 

    • Frameworks are hard to learn and this knowledge is generally useless
    • Frameworks limit your scope of creativity
    • Frameworks increase your project’s complexity and dependencies
    • Frameworks go out of business
    • Frameworks evolve and you have to spend time upgrading your framework versions and other dependencies.
    • You have to ask others for help
    • You probably only need just a few of framework’s features
    • Use frameworks only when absolutely necessary
    • Friends don’t let friends use frameworks


  • Collin Anderson 6:10 pm on March 3, 2016 Permalink | Reply  

    Etsy CTO Q&A: We Need Software Engineers, Not Developers 

    Quotes from http://thenewstack.io/etsy-cto-qa-need-software-engineers-not-developers/

    The architecture is relatively straightforward. At a high level, there’s not too much that’s overly complicated, and I think we prefer it that way: PHP, Linux, and Apache, and MySQL

    We want to exploit all of the advantages that come from having a small number of well-known tools. When you have a small number of well-known tools, you can then focus on the product. We don’t want to be doing engineering for engineering’s sake, and much in the same way that you wouldn’t want a carpenter to be overly concerned about what kind of hammer he has — at some point, it doesn’t matter.

    One of the things that we’ve done for a number of years is to recognize that if you’re going to solve a problem, and you think you need to solve it in a new and novel way that can’t be solved with the technology stack or the patterns that we already have — then that’s fine, it’s just that we need to be explicit about the operational costs of doing so. Introducing something new and different can bear a huge long-term cost to the organization.

    what I want to do is I want to ask the greater population of engineers at the company, “Hey, I’m working on this problem. I think the only way to solve it is by using this brand-new thing that nobody knows about. Please talk me out of this.”

    engineers need to have the same [pride of ownership], to say “This is my code; I take responsibility for it, whether it’s successful or not successful.”

    are you abstracting away so that you truly can say “I don’t have to worry about this”? Or are you abstracting away because you’re aware of those guts, but want to focus your attention right now in this area. That is what we’re looking for. Post-mortem debriefings every day are littered with the artifacts of people insisting, the second before an outage, that “I don’t have to care about that.” If “abstracting away” is nothing for you but a euphemism for “Not my job,” “I don’t care about that,” or “I’m not interested in that,” I think Etsy might not be the place for you. Because when things break, when things don’t behave the way they’re expected to, you can’t hold up your arms and say “Not my problem.”

    Engineering, as a discipline and as an activity, is multi-disciplinary. It’s just messy.

    As an engineer who starts day one, I am [not] the best one to know how network protocols at Etsy work, and I’m going to be encouraged to seek out the experts in those domains until I do. And maybe something will break, and then I’m going to learn something new. … I need to continually expect that part of my job is exploring the boundary — what’s the precipice of my knowledge — and keep going.

    The promise of things like machine learning is that it paints a picture of the future where software will be able to make all of these decisions and that humans’ judgment will always be faulty. I think that there’s a huge miss there in that perspective. This is the reason we’ve said that we want to take a human-centered approach to engineering at Etsy. We can pretend as much as we want that the algorithms will make everything great and perfect, but that’s only when we view humans as frail, faulty, error-prone, cause of accidents, that sort of thing, and it’s simply false. The fact of the matter is, accidents and failures happen way less often than success. And so to pull back the high-level view, at Etsy, this is not just sort of an empty thing. We want to view engineering as engineering, and not be clouded by rose-colored algorithmic glasses.

  • Collin Anderson 12:57 pm on March 2, 2016 Permalink | Reply  

    How To Deploy Software 

    (quotes from an article)

    Make your team’s deploys as boring as hell and stop stressing about it.

    start with a good foundation: have good tests. Don’t skimp out on this, because it impacts everything else down the line.

    How fast should fast really be? GitHub’s tests generally ran within 2-3 minutes while I was there.

    [Feature Flags let you] test code in the real world with real data and make sure things work and “feel right”

    You should also be using pull requests, merge requests, or other code review to keep track of discussion on the code you’re introducing.

    Your branch is your responsibility … If it breaks, you fix it

    Start reviews early and often. … If you can open a code review with imaginary code to gauge interest in the interface, for example, those twenty minutes spent doing that and getting told “no, let’s not do this” is far preferable than blowing two weeks on that full implementation instead.

    build software using quick, tiny branches and pull requests. Make them small enough to where it’s easy for someone to drop in and review your pull in a couple minutes or less. If you build massive branches, it will take a massive amount of time for someone else to review your work, and that leads to a general slow-down with the pace of development. … This is where those feature flags from earlier come into play.

    Again, the smaller the diff, the more boring, straightforward, and stress-free your deploys become.

    Branch deploys: When you’re ready to deploy your new code, you should always deploy your branch before merging. Always.

    Whatever you have on your master branch … should be noted as being the absolute reflection of what is on production. In other words, you can always be sure that your master branch is “good” and is a known state where the software isn’t breaking. … If you merge your branch first into master and then deploy master, you no longer have an easy way to determining what your good, known state is without doing an icky rollback in version control.

    The benefit of some type of audit trail for your deployments is basically what you’d expect: you’d be able to find out who deployed what to where and when. Every now and then you’ll run into problems that don’t manifest themselves until hours, days, or weeks after deployment, and being able to jump back and tie it to a specific code change can save you a lot of time.

    Deploy locking is basically what you’d expect it to be: locking production so that only one person can deploy code at a time. There’s many ways to do this, but the important part is that you make this visible.

    A deploy queue has a couple parts: 1) if there’s a wait, add your name to the end of the list, and 2) allow for people to cut the line (sometimes Really Important Deploys Need To Happen Right This Minute and you need to allow for that).

    The final bit of housework that’s required is the cleanup. … One approach I liked to take was to prepare two pull requests: one that toggles the feature flag (i.e., ships the feature to everyone), and one that cleans up and removes all the excess code you introduced. … You should celebrate this internally, too: it’s the final sign that your coworker has successfully finished what they were working on. And everyone likes it when a diff is almost entirely red. Removing code is fun.

    I only get emotional about two things: a moving photo of a Golden Retriever leaning with her best friend on top of a hill overlooking an ocean looking towards a beautiful sunset, and deployment workflows.

    At the end of the day, I care about two things: how my coworkers are feeling, and how good the product I’m working on is. Everything else stems from those two aspects for me.

    Spend some time and get your deploys to be as boring, straightforward, and stress-free as possible. It’ll pay off.


  • Collin Anderson 4:10 pm on February 27, 2016 Permalink | Reply  

    What Google Learned from its Quest to Build the Perfect Team 


    “First, on the good teams, members spoke in roughly the same proportion”
    “Second, the good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues.”
    ‘‘shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’
    ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,’’
    ‘‘a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

    However, establishing psychological safety is, by its very nature, somewhat messy and difficult to implement. You can tell people to take turns during a conversation and to listen to one another more. You can instruct employees to be sensitive to how their colleagues feel and to notice when someone seems upset. But the kinds of people who work at Google are often the ones who became software engineers because they wanted to avoid talking about feelings in the first place.

  • Collin Anderson 9:33 am on February 16, 2016 Permalink | Reply  

    Write code that is easy to delete, not easy to extend. 

    Every line of code written comes at a price: maintenance. To avoid paying for a lot of code, we build reusable software. The problem with code re-use is that it gets in the way of changing your mind later on.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc

Get every new post delivered to your Inbox.