| I've worked as a contractor for John Deere, and I can vouch for "inexperienced and mismanaged development". I was working on the embedded side of the business, not the API side. Some interesting observations: * John Deere didn't hire anyone for a Software Engineering job unless they were a licensed engineer, at least in the area that I worked in. This meant a lot of EE and CE majors were writing the software and they pretty much all viewed software dev as "a foot in the door" to do the hardware work to which they aspired. This may not have been true across the company (perhaps only in the area that I worked in) and it may not be true today. * This also manifest in a culture that was utterly divorced from the rest of the software industry. They're just moving from subversion to git, much of their "CI/CD pipeline" was built with windows .bat scripts and code generation via excel files that take hours to run (I shit thee not). They build pretty much everything in-house from hardware to embedded operating systems, and their embedded codebases are littered with #ifdefs to conditionally compile different code snippets based on the specific model of tractor/comine/sprayer/etc and feature set that it is to be loaded onto. It's hard to put into writing how difficult this is to maintain. * They build everything in-house, but it's a big company and people just email around binaries for various development tools with no way to find the source code or even the author except to ask around. Submitting a patch to a dev tool is an enormous effort. Word is they're moving to GitHub, and I think it's going to be a game changer for developers. * Other than that, there's a long tail of other problems. IT seems to have management paranoid that if developers are too productive the hackers will steal their IP and the company will go under or something. So getting a server provisioned is a months-long affair and teams will occasionally just run a Jenkins server from a former coworker's desktop that IT forgot to pick up. There's a culture of "don't try to improve things that aren't immediately in your purview". They routinely pick tools that are abysmal to work with--I don't mean "everyone has different preferences", I mean "they bought SharePoint and made everyone use it, but didn't pay for the SharePoint consultants who program the software to be actually usable within an organization (I'm generously assuming that it's possible to make SharePoint usable--I'm not sure this is the case). All of that said, John Deere has some really cool problems that would be really fun to work on if not for all of their organizational issues. They had self driving tech years before anyone else, they have a vast array of vehicles that run these distributed networks of embedded controllers, they make their own hardware and software (which could be a lot of fun to work on if managed properly), they aspire to use ag data to improve yields and have a credible path forward (as opposed to the "step 1: use big data, step 2: profit!" sense). Additionally, I think they probably are innovative and well-run in many non-software respects, but I'm not qualified to comment. Similarly, for all of its issues (including hostility toward folks who want to repair their vehicles), I really want them to turn a corner and succeed because agtech is really cool and they're an American Icon with a (increasingly tarnished) reputation for quality, innovation, and providing quality jobs. I wish them the best and maybe one day I'll apply and try and help from within. |