google reader refugee.
2054 stories

Four short links: 5 October 2018

1 Share

Supply Chain Security, ML in FB Marketplace, Datasette Ideas, and Scraper DSL

  1. Motherboard Supply Chain Compromise (Bloomberg) -- fascinating story of Chinese compromise of SuperMicro motherboards, causing headaches for AWS, Apple, and the U.S. military, among many others. See also tech for spotting these things and some sanity checking on the article's claims.
  2. How Facebook Marketplace Uses Machine Learning -- nice. It's increasingly clear there's not much that's user-facing that can't benefit from machine learning to prompt, augment, and check user input.
  3. Interesting Ideas in Datasette (Simon Willison) -- solid technical reflection on non-obvious approaches and techniques in his project.
  4. Ferret -- interesting approach: a DSL for writing web scrapers.

Continue reading Four short links: 5 October 2018.

Read the whole story
14 days ago
Melbourne, Australia
Share this story


1 Share

Everyone likes to talk about leadership—we are culturally conditioned to view success as a progression through leadership positions—but there is far less attention paid to being a good follower. In fact, when most people think of themselves as followers, it’s often accompanied with negative feelings, like being judged as meek or submissive. As if being a follower comes at the expense of being a leader. But in reality, every leader in an organization is following someone, and so it serves us well to remember to live up to those responsibilities.

Models of Followership

There are many models of Followership out there that give us a handy way of understanding follower behaviors for our reports and for ourselves. One model I’m fond of is the Chaleff model which describes two axes: the degree of support a follower gives a leader and the degree to which the follower is willing to question or challenge the leader’s behavior or policies. These axes give rise to four distinct follower styles:

Implementers demonstrate high support but low challenge. They are workhorses, in that they take orders and don’t ask questions. It’s easy to love this type of follower more than others because they just get things done. The downside is that they won’t speak up when they see that the direction is not aligned with the company’s ideals or vision.

Resources display low support and low challenge. They do what is requested of them, but little more. In general this type of followership shows up to work and does just enough to retain their position and no more. They’re just trying to get by.

Individualists demonstrate low support and high challenge. They tend to think for themselves and prefer to do as they want. This type of follower will speak up when others are silent, but is often marginalized due to being habitually antagonistic.

Partners display both high support and high challenge. They are strong supporters but will provide challenge where they deem necessary. These types of followers take full responsibility for their own, as well as the leader’s behaviors and act accordingly. They give their whole heart to the corporate vision and the initiatives of the leader, but are open and honest enough to speak up when something doesn’t mesh with the best interests of the organization.


Image of Chaleff Model of Followership

Practical Application

To date, I’ve used this model in a number of ways. The first being, at a basic level, just helping me understand the types of folks in my organization and how to bring them together into productive teams. Identifying potential tech leads (partners) with a supporting cast and being cognizant of the difficulties that might occur if an individualist gets that role.

I’ve also used followership concepts to frame career paths by setting expectations around follower behaviors at every level on the career ladder. Starting Engineers aren’t expected to be implementers or partners. Software Engineers, however, should be strong implementers, and Senior Software Engineers and above should be developing their ability to be partners. With those expectations set, I can ask interesting career progression questions. Followership gives me a framework to direct my feedback. For example, Engineer A needs to grow from a resource into an implementer. Or, Engineer B is too much of an individualist, and I need them to be a partner.

In a day-to-day leadership role, I use followership to keep me honest about embracing and rewarding strong partners. When words are spoken that I’d prefer not to hear, understanding followership helps me remember the positives of being challenged, and I would be well served to consider what is being said rather than dismiss it out of hand. It helps me avoid labeling people as troublemakers when they may, in fact, be influencing me in a better direction.

And finally, I’ve used followership to evaluate how I am following my manager. I have an imperative to express challenge when I feel strongly about something in the company’s interest. How am I living up to that responsibility? When my manager makes a decision, how am I undercutting or supporting them? What kind of follower does my manager need right now? These questions help me understand my performance and how I’m showing up in my role.


Good followers can influence leaders in positive ways that don’t always come in pleasant packages. Some of the most impactful work I’ve done has come as a result of listening to folks who disagreed with me. Moving beyond the concept of followers as just “people who do the work,” and adopting followership has helped me in numerous ways. As a follower, it helps clarify my responsibility to speak out and show support when appropriate. As a leader, followership reminds me that when I hear disagreement, it’s an opportunity to take a beat, listen, and appreciate.

The post Followership appeared first on Jason Wong's Blog.

Read the whole story
19 days ago
Melbourne, Australia
Share this story

Career narratives.

1 Share

A peculiar challenge of management is trying to invest in someone's career development when they themselves are uncertain about their goals. As a manager, you may have more experience and more access to opportunities within the company, but that represents a small slice of someone's career possibilities. Our schooling often rewards us for being methodical, linear thinkers, but that approach is less effective outside the intentionally constrained possibility spaces.

The options for approaching a career, particularly for those of us priviledged to work in technology, are so extraordinarily vast that exploring them effectively requires a different approach. This vastness also means that you, as a manager, can't simply give folks a career path: you'll inevitably steer them towards the most obvious avenues and through avoidable competition.

Flipping perspectives, it's also quite challenging to plan your own career. I sometimes find myself walking from one meeting where I'm coaching someone on their career goals, straight into a second meeting where I struggled to string together words to articulate my own. The hardest bit is that most folks are always at the furtherest point in their career, each change a step into the unknown, with limited visibility into the upcoming opportunities that their company can provide.

The intersection I've found between the individual's and their manager's perspective is the career narrative. I've mentioned these fabled documents a few times before, in Roles over rocket ships and Partnering with your manager, but given how useful they can be, it's useful to expand a bit on the process of maintaining one.

Artificial competition

If you took ten minutes to ask a dozen folks about their immediate career goals, I suspect that for eleven of them it would center on either getting promoted or switching companies to reach the next evolution of their current job. This doesn't mean that climbing the career ladder is bad, that's what it's designed for, but it has the side effect of funneling most folks towards a constrained pool of opportunity.

What I've slowly but increasingly come to believe is that there is much more opportunity outside career ladders than within them, and by including those opportunities you'll make and feel more progress. Better yet, you'll find far more opportunities to partner with your peers, no longer competing for limited promotion slots.

For example, if your long-term goal is to be the head of engineering at a mid-size company, you could approach that linearly by trying to expand your role bit-by-bit at your current company on the track to becoming its head of engineering. That'll work for roughly one person at the company, but for everyone else pursuing that same path it will probably be suboptimal.

A different approach would be to instead work on identifying your gaps to be a strong head of engineering, and then start using your current role to help fill those gaps in. A prototypical head of engineering will be skilled at organizational design, process design, business strategy, recruiting, mentoring, coaching, public speaking, written communication, have a broad personal network, and have a broad foundation from product engineering to infrastructure engineering. That's not even a particularly complete list of relevant skills! There are so many different aspects of to build out, and you can find opportunities to practice all of them in your current role; no need to convince yourself your current role is holding you back, everything you need is here.

Importantly, while generalized career paths won't necessary align cleanly with your goals, they also are unlikely to take full advantage of your strengths. While an important part of setting your goals is developing areas you're less experienced in to maximize your global success, it's equally important to succeed locally within your current environment by prioritizing doing what you do well.

With all of this in mind, take an hour and write up as many goals as you can for what you'd like to accomplish in the next one to five years. Then prioritize the list, pick a few that you'd like to focus on for the next three to six months, and share it with your manager to discuss at your next one-on-one.

Translating goals

Once you've identified goals to pursue, the next step is to translate those goals into actions, and this is where your manager can be a leveraged partner in interating on your career narrative.

Managers tend to have a strong sense of the business' needs, and that gives them the superpower of finding the intersection of your interests and the business' priorities. That translation is a creative pursuit, so don't leave this entirely to your manager: participate as well! Brainstorm projects, research how folks at other companies have pursued similar goals, educate your manager on aspects of your goals they don't know much about (for example, engineers often have more conference speaking experience than engineering managers).

Bringing your list of goals to this discussion helps ensure it's successful. If you don't bring a rough draft, by default you'll get steered towards the contested commons, and your career narrative will be a dull instrument for progress.

This refined list of goals, aligned to your company's priorities, then becomes a central artifact for how you and your manager partner on your career evolution. Every quarter or so, take some time to refresh the document and review it together.

If you're unconvinced it's worth your time to write a career narrative, you certainly don't have to write one Most folks get away without writing one for their entire career and have deeply fulling careers despite the absence.

That said, if you don't, then there is probably no one guiding your career. Chasing the next promotion is at best a marker on a mass-produced treasure map, with every shovel and metal detector recovering the same patch. Don't go there. Go somewhere that's disproportionately valuable to you because of who you are and what you want.

Read the whole story
19 days ago
Melbourne, Australia
Share this story

Some possible career goals


I was thinking about career goals a person could have (as a software developer) this morning, and it occurred to me that there are a lot of possible goals! So I asked folks on Twitter what some possible goals were and got a lot of answers.

This list intentionally has big goals and small goals, and goals in very different directions. It definitely does not attempt to tell you what sorts of goals you should have. I’m not sure yet whether it’s helpful or not but here it is just in case :)

I’ve separated them into some very rough categories. Also I feel like there’s a lot missing from this list still, and I’d be happy to hear what’s missing on twitter.

technical goals

  • become an expert in a domain/technology/language (databases, machine learning, Python)
  • get to a point where you can drop into new situations or technologies and quickly start making a big impact
  • do research-y work / something that’s never been done before
  • satisfy your intellectual curiosity about something
  • get comfortable with really big codebases
  • work on a system that has X scale/complexity (millions of requests per second, etc)
  • scale a project way past its original design goals
  • do work that saves the company a large amount of money
  • be an incident commander for an incident and run the postmortem
  • make an contribution to an open source project
  • get better at some skill (testing / debugging / a programming language / machine learning)
  • become a core maintainer for an important OSS project
  • build an important system from scratch
  • be involved with a product/project from start to end (over several years)
  • understand how complex systems fail (and how to make them not fail)
  • be able to build prototypes quickly for new ideas

job goals

  • get your first job
  • pass a programming interview
  • get your “dream job” (if you have one)
  • work at a prestigious company
  • work at a very small company
  • work at a company for a really long time (to see how things play out over time)
  • work at lots of different companies (to get lots of different perspectives)
  • get a raise
  • become a manager
  • get to a specific title (“architect”, “senior engineer”, “CTO”, “developer evangelist”, “principal engineer”)
  • work at a nonprofit / company where you believe in the mission
  • work on a product that your family / friends would recognize
  • work in many different fields
  • work in a specific field you care about (transit, security, government)
  • get paid to work on a specific project (eg the linux kernel)
  • as an academic, have stable funding to work towards your research interests
  • become a baker / work on something else entirely :)

entrepreneurship goals

This category is obviously pretty big (there are lots of start-your-own-business related goals!) and I’m not going to try to be exhaustive.

  • start freelancing
  • start a consulting company
  • make your first sale of software you wrote
  • get VC funding / start a startup
  • get to X milestone with a company you started

product goals

I think the difference between “technical goals” and “product goals” is pretty interesting – this area is more about the impact that your programs have on the people who use them than what those programs consist of technically.

  • do your work in a specific way that you care about (eg make websites that are accessible)
  • build tools for people who you work with directly (this can be so fun!!)
  • make a big difference to a system you care about (eg “internet security”)
  • do work that helps solve an important problem (climate change, etc)
  • work in a team/project whose product affects more than a million people
  • work on a product that people love
  • build developer tools

people/leadership goals

  • help new people on your team get started
  • help someone get a job/opportunity that they wouldn’t have had otherwise
  • mentor someone and see them get better over time
  • “be a blessing to others you wished someone else was to you”
  • be a union organizer / promote fairness at work
  • build a more inclusive team
  • build a community that matters to people (via a meetup group or otherwise)

communication / community goals

  • write a technical book
  • give a talk (meetup, conference talk, keynote)
  • give a talk at a really prestigious conference / in front of people you respect
  • give a workshop on something you know really well
  • start a conference
  • write a popular blog / an article that gets upvoted a lot
  • teach a class (eg at a high school / college)
  • change the way folks in the industry think about something (eg blameless postmortems, fairness in machine learning)

work environment goals

A lot of people talked about the flexibility to choose their own work environment / hours (eg “work remotely”).

  • get flexible hours
  • work remotely
  • get your own office
  • work in a place where you feel accepted/included
  • work with people who share your values (this involves knowing what your values are! :) )
  • work with people who are very experienced / skilled
  • have good health insurance / benefits
  • make X amount of money

other goals

  • remain as curious and in love with programming as the first time I did it

nobody can tell you what your goals are

This post came out of reading this blog post about how your company’s career ladder is probably not the same as your goals and chasing the next promotion may not be the best way to achieve them.

I’ve been lucky enough to have a lot of my basic goals met (“make money”, “learn a lot of things at work”, “work with kind and very competent people”), and after that I’ve found it hard to figure out which of all of these milestones here will actually feel meaningful to me! Sometimes I will achieve a new goal and find that it doesn’t feel very satisfying to have done it. And other times I will do something that I didn’t think was a huge deal to me, but feel really proud of it afterwards.

So it feels pretty useful to me to write down these things and think “do I really want to work at FANCY_COMPANY? would that feel good? do I care about working at a nonprofit? do I want to learn how to build software products that lots of people use? do I want to work on an application that serves a million requests per second? When I accomplished that goal in the past, did it actually feel meaningful, or did I not really care?”

Read the whole story
20 days ago
Melbourne, Australia
Share this story

my team doesn’t ask managers to hang out with them

1 Share

A reader writes:

I have a small tight-knit team of eight people. The people that I’ve hired in the last two years socialize together quite a bit, which is great. The downside is they don’t invite me or the other managers; the junior members will hang out together and not invite the managers. The disappointing part of this is that this team has historically been very tight and (we hoped) didn’t feel hierarchical. As we hire more people, I would prefer that the environment feel inclusive. It’s a little awkward when five people spent their weekend together and are talking about it and the remaining three weren’t invited.

Recently at a team dinner one of them said to someone outside the department that “everyone went” to an event together. The person asked me if I had gone and I said, I hadn’t been invited. My team member said I wouldn’t have gone anyway.

The managers do have babies or life responsibilities that keep us from socializing together after hours. We also have more friends outside of work than most of the junior members so the likelihood of us participating is low. But we still would like to be asked and feel a little hurt to be left out while recognizing that the team should feel free to hang without being obligated to ask us to come. I guess they don’t want their supervisors to come along and that is tricky for us because we really encourage a “flat” culture and it’s put a small us vs. them vibe into the team.

I’m not exactly sure the best way to handle this or if there’s anything to handle at all.

Nope, there’s nothing to handle!

It’s very normal for people not to socialize with their managers. And in fact, that’s far preferable.

To be clear, there’s nothing wrong with a manager occasionally grabbling drinks or dinner with their team! That’s fine. But managers should not typically be a regular presence in their teams’ after-hours socializing.

The reality is, flat culture or no, there are power dynamics in your relationships with the people you manage, and it’s not good for either side to blur those boundaries. You are still the person charged with assessing their work, giving them feedback, delivering bad news, evaluating them for raises and promotions, and potentially laying them off or firing them one day. You need to be able to do all of those things objectively, and — equally as important — you need people to believe that you’re doing all of those things objectively. That’s much harder to pull off when you’re regularly socializing with people who report to you (again, beyond the occasional drink or meal).

I know you’re not saying you necessarily would attend these social events; you just want to be asked. But that’s putting an inappropriate social expectation on your staff and ignoring the realities of your respective roles.

Frankly, it’s not necessarily great that your junior staff are all hanging out together this much either. There’s not really anything you can or should do about that, but be aware that it can sometimes cause problems of its own — like if one of them has a problem with her manager and the others decide to fight that as their own battle too, or if people develop group-think, or if they don’t like your next junior hire and she ends up feeling excluded, or if your next junior hire doesn’t want to hang out with coworkers this much but feels the culture expects her to, or if it just makes people feel like they can’t disconnect from work. It can also be a sign that you don’t have as much diversity on your team as you should — that you’re not, for example, hiring people who are older or who have kids or so forth.

But the immediate issue here is that you’ve got to reset your ideas about relationships with employees. You can and should have warm and friendly relationships with your employees, but you can’t ignore the power dynamics inherent in your roles. It’s not fair to expect them to treat you like peers or to be hurt if they don’t invite you to socialize.

Now, certainly if you see the group dynamics start to cause specific problems, that’s different. For example, if you felt that your junior employees were starting to act as a group when they should be acting as individuals — like filtering their ideas through each other and never suggesting anything without group approval, or spreading cynicism or toxicity — you’d need to address that. But you’d be addressing that specific manifestation, not the fact that they hang out together.

my team doesn’t ask managers to hang out with them was originally published by Alison Green on Ask a Manager.

Read the whole story
22 days ago
Melbourne, Australia
Share this story


1 Comment and 2 Shares

Apple rejected Greg Knauss’s app for mentioning the names of the new iPhones they’d already announced

Read the whole story
28 days ago
Melbourne, Australia
Share this story
1 public comment
15 days ago
Apple is dumb.
Next Page of Stories