Recent Updates Toggle Comment Threads | Keyboard Shortcuts

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

    https://m.signalvnoise.com/you-aren-t-gonna-need-to-design-it-997349d7cc20

    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.

    http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html?m=1
    http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/

     
  • 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

    http://www.catonmat.net/blog/frameworks-dont-make-sense/

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

    https://zachholman.com/posts/deploying-software

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

    What Google Learned from its Quest to Build the Perfect Team 

    http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

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

     
  • Collin Anderson 12:12 pm on February 12, 2016 Permalink | Reply  

    10 Rules of Running a Remote Team 

    Set both short and long-term goals
    Choose the right tools
    Make sure everyone knows the procedures
    Focus on communication and transparency
    Recognize the impact of inclusiveness
    Continuously track the progress of projects
    Motivate your team and trust them
    Put emphasis on team-building both offline and online
    Foster a culture of mutual feedback and knowledge exchange
    Care about your working environment

    https://www.netguru.co/blog/10-commandments-of-running-a-remote-team

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel
Follow

Get every new post delivered to your Inbox.