rparet

You're not alone. I definitely feel like this is / will be a major adaptation required for software engineers going forward. I don't have any solutions to offer you - but I will say that the state that's enabled by fast feedback loops wasn't always the case. For most of my career build times were much, much longer than they are today, as an example. We had to work around that to maintain flow, and we'll have to work around this, now.

(I work for the OP company) We use Cursor's bugbot to achieve the same thing. Agree that it seems better than Copilot for now.

I was fortunate enough to visit back in 2018. It’s so nice to see this persevere.

This is completely untrue. Google “adverse impact hr” for a quick education on this topic.

(I am not a lawyer) It’s ok in the US to have a goal to hire more women or URMs, and to do sourcing, etc. to bring in more candidates like this. I think the potential concerns here are the use of “must” in the spreadsheet, and what activities you’ll be expected to perform, OP. I’d recommend advocating for changing “must” to some other goal-based language. If you’re doing the sourcing, I’d also think about setting goals here (x% of candidates moved from stage 1 to stage 2 are women/urms, for example). What’s not ok: * not interviewing or hiring someone because they are not a woman * giving someone a different interview for any reason (barring accommodations for disabilities, etc) * saying “we are only hiring women for this role” (for example) * saying “we are not hiring any men for this role” (for example) * having a quota that must be met. (i.e. a target, not a goal).

There are ways that this can play out that might seem discriminatory but are not. For example, if your goal is to have X% of final stage candidates be women and you haven’t gotten there yet, not hiring a non-woman final stage candidate that is otherwise hirable is not discriminatory. See the “Rooney rule” and other examples.

What I think you should do: * assume positive intent. No one person is responsible for this systemic shitshow / imbalance, and people are doing the best they can to fix it. Understanding how to do that in the context of the law is sometimes difficult. * advocate for the use of appropriate goals that support the initiative. * politely object when someone asks you to do one of the “should not dos” above. Ask them to restate in the context of goals. * don’t get caught up in culture warrior nonsense that circulates around this issue. You’re an engineer, recruitment is a system. Treat it like a systems problem. * support your women colleagues and women in tech in general. Systemic bias is real. People who believe women shouldn’t be in tech exist. Do what you can to help overcome these obstacles.

Went to github, saw the word “sprint”, closed window. I really appreciate any effort to return us to basics. However, we should have a firm grasp on what the basics are first. Today, you wouldn’t batch all of your team’s code together this week and then do a build - you would build and integrate continually. Why would you adopt large batch, non-continuous process for your overall development process?

ah, how unfortunate! as a user, would love to see some / all of their stuff become open sourced, if possible.

It was mentioned before in the thread, but I'll just go ahead and leave this here again:

http://en.wikipedia.org/wiki/Planning_fallacy

Trying to improve developer estimates is just another case of doing the wrong thing, righter.

tl;dr: author of the article is laboring under many false assumptions about Kanban (and lean software development in general) likely due to a combination of inexperience using such methods personally and unfamiliarity with the available literature. The following is a rather long attempt to correct the base misunderstandings in the article, with pointers to relevant source material. Enjoy!

First, an operational definition: Kanban as it's used in lean software development is 1. visual representation of the work that's in the system and what state it is in and 2. an opportunity to limit the amount of work that can be in each state.

That's it.

Almost every organization that writes software uses something to keep track of the work, and what state it is in - by this logic the title of the article could be "spreadsheets - the secret engineer killer", or "JIRA - the secret engineer killer".

According to the article though, Kanban is ruining engineering teams in "nearly every company" that has adopted Kanban out of the 150 companies the author talked to in the last 60 days. (Some numbers on how many of them are using Kanban, and for how long, would have been nice facts to include, btw.)

So, let's unpack some reasons why this is:

"Engineers are not assembly line workers" - Implying Kanban and pull-based systems only work for "widget producers" and forces engineers to focus on the individual trees, not the forest. I think this sort of highlights the author's misunderstanding of Kanban (and to an extent any pull-based system) and what role it serves in an organization. Kanban isn't magic - it not an organizational design, it's not a product development strategy, and it's definitely not a substitute for leadership. It's a chart on a wall that shows what the work of the product development organization looks like, right now.

For an example of an overall software product development strategy that incorporates pull-based systems as one component, I recommend checking out "Principles of Product Development Flow" by Don Reinertsen.

"It teaches you that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects." - How does it do this? Nothing about Kanban implies no estimates. In fact if you use Kanban and measure cycle time, you will be doing evidence-based scheduling which will allow you to make better estimates. As for "complex multi-faceted projects" - I don't know what the author is talking about. Please read "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde for some actual evidence and lessons learned on lean / agile approaches being used on huge software projects. Also "Scaling Agile at Spotify" by Henrik Kniberg is worth a read, as Kanban features there (by team choice!) as one small component in a lean software development org design / product development strategy.

"Kanban forces a 'one work item at a time' mentality and resists milestones." This is simply not true and such a basic misunderstanding I have to wonder if the author of the article has taken the time to read any of the introductory literature. If not, I suggest the aptly titled "Kanban" by David J. Anderson. Kanban wants you to limit work in progress, which is one of the basic goals of any product development system. It doesn't say how much it should be limited, or where it should be limited. Every system, everywhere, already has limited-WIP in the form of bottlenecks. The hopeful goal of pull-based systems in general and lean software development specifically is that you'll use these simple tools to look at your process and eliminate wasteful activities and streamline those bottlenecks that must exist to deliver maximum value to your customers. In this sense, you can use Kanban as a tool to maximize the whole of the product development process which is certainly a macro (org level) goal and outcome that stands in stark contrast to the claims in the article that Kanban in general promotes micro optimizations and misses the big picture.

For more general reading on why limiting work in progress is a good idea, I suggest "The Goal" by Eli Goldratt or more recently "The Phoenix Project" by Gene Kim. As far as milestones go, nothing in a pull-based system is incompatible with milestones of fixed date or fixed scope. If your idea of milestones is chucking arbitrary dates on a calendar based on an estimate before work begins and then stubbornly refusing to adapt those milestones when the situation on the ground changes (i.e. milestones of fixed date and fixed scope), then I could see the potential nature for conflict, but surely you're not out there doing that in real life, right? (Right???) If you are, and that's the issue - Kanban isn't the problem, the problem is the assumptions you are operating on are faulty - nothing will work for you. Smarter folks than me have written about the perils of fixed date and fixed scope development, I suggest googling for Neil Killick's thoughts on the matter.

"High performance individuals and companies are goal and date driven." Citation needed. I know many people really, really believe this but you should really verify. Also, see Fred Brooks "Mythical Man Month".

"Kanban was never intended for software development" - What? Again, the guy you quote actually wrote a book on using Kanban with software development teams. You should read it, as it would probably correct 90% of the misunderstandings in your article.

Those are the key arguments in the article about why Kanban is "the secret engineer killer". Hopefully by now it's clear that these arguments aren't very good and it certainly wasn't any trouble for me to refute them along with a bibliography for further reading. That doesn't mean Kanban or lean are perfect though - there still is no silver bullet. Hopefully this inspires some folks to launch a more throughly-researched critique of lean, kanban, or pull-based systems in the future as I think that kind of discussion can be really beneficial.

nice to see Ray Dalio's principles get a shoutout, although I wouldn't necessarily describe it as a "culture guide". Seems like there could be a section here on "system building".

...or it's rebranding to match the name of its parent company, Japanese-based Rakuten. http://en.wikipedia.org/wiki/Rakuten

How does this compare to security offerings from other BaaS providers like Kinvey, Parse, etc?

++ if you can, you should work with Jon. He's great to work with and you'll learn a lot.

Interesting case giving up MongoDB because of the complexity of adapting another application to use it. I wonder if this is a good use case for something like http://www.nuodb.com/

Cambridge, MA - Full time Engineers at Crashlytics (http://www.crashlytics.com)

Frontend, Backend, iOS and Android. Mobile apps crash over 1 billion times a day - let's do something about it!

Crashlytics is the most powerful and lightweight crash reporting and analysis service for iOS and Android. If you're interested in the intersection of great UX, scalable systems, the mobile internet, and big data analytics we want to talk to you!

We're an early stage startup looking for truly talented engineers with a passion for clean code and great products. Our team is fast, smart and independent -- with previous startup success.

We're small and growing rapidly, so it's important to us to have a great company culture to support that growth. We offer all of the usual startup perks: snacks in the kitchen, flexible work schedule, top-of-the-line gear (Macbook Air, Thunderbolt display, iPad/Android Tablet), etc. Additionally, we feel strongly that it's the culture created by shared values that really makes Crashlytics a great place to work.

Here's a brief look at a few of the things we value: We focus on the modern web - We don't support IE6, so you'll never have to worry about it! We love feedback - you’ll be able to connect directly with customers who are using what you’re building and use their input to make the product better. We’re self-directed - We trust you to manage your own schedule, vacation, etc. without complex policies or forms to fill out. We ship - we're huge fans of TDD, build/measure/learn, and are moving towards continuous deployment. We give back - We encourage open source contributions and community participation. We’re hyper technical - Deep understanding and optimization are in our soul - what can your code accomplish in 18ms?

Interested? Say hello to us at jobs at crashlytics dot com