(Hiring) Companies that follow these practices

[Durant Schoon]

Hi,

I really enjoyed reading this book on kindle this year. After I practice for job interviews this summer, I plan on re-entering the workforce as a software engineer (It's my 2nd career. I've had one job with two years experience). Can anyone speak to which companies are known or reported to follow the best practices described by the book? I'm interested in joining a company that is already in the mindset that these are the right practices while trying to follow them. Why not join a company that will make me the best engineer I can be? It seems appropriate to let companies know that these issues matter to would-be employees. Maybe not everyone cares, but I'd expect most people on this list would.

Also relevant would be stories of how how hard or easy it is to get a company to change their way to employ this-way/these-ways of thinking. 

Thanks,

[Gregg Irwin]

I only recently discovered the book myself, and don't know of anyone else who has read it in my limited circle. I'm also interested to know where the ideas have gained traction. They resonate strongly with me, but I've always been a fringe dweller. I also think "That sounds like common sense!" but clearly it isn't in the wider world. It's also likely the case that the ideas from the book, given time and success, would be co-opted in the same way that other methodologies have. At least some. i.e. the less prescriptive and more flexible and broad the ideas, the less people can make money from them and build industries up around them. I feel a rant coming on, so I should stop now. 

IME it can be very hard to change culture that is deeply entrenched, and exists at scale. Pressure from the top helps. 

[John Ousterhout]

Hi Durant,

I don't have enough information to identify specific companies that are (or are not) willing to invest in good software design. For companies of any size, I think this is likely to vary from group to group within the company.

I'm much more certain about your second question: once an organization has established a particular style, whether good or bad, it's extremely difficult to get it to change. In general, it's unwise to enter into any relationship with the expectation that the other party will make significant changes.

-John-

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/software-design-book/9f8310dd-721d-405a-8202-5731e4710a2cn%40googlegroups.com.

[Peter Ludemann]

From my personal experience (~40 years of software development), there are a few things that can point to good software development practices:

- Is software a profit center or a cost center? If it's a profit center, the company will invest in tools and will look for quality code; if it's a cost center, they'll apply a short-sighted "low cost" mindset. See also: 

https://twitter.com/GergelyOrosz/status/1544081817594118145 https://twitter.com/GergelyOrosz/status/1543963714575106055

- Do senior management have a technical background?

- Is there a career path for engineers, or is the expectation that you must go into management to advance in your career?

- Is there a design review and code review culture? Are there good development tools?

- Are people encouraged to move from group to group over the years?

It can be tricky to figure this out from the outside. For example, when I was at IBM in the late 80s, a lot of the senior management came from sales or marketing, even within the development organization (this was somewhat balanced by managers having a staff "Technical Advisor", who was at a similar pay grade to the manager). [This was also a period when IBM started undergoing massive change, and many of the "old guard" programmers were swept away or retired - I didn't stay to see whether the transformation was successful]

At another company (a now defunct startup), I encountered a culture where people were implicitly encouraged to take design and quality short-cuts, even though the company's main product was a network deployment framework where the selling point was high reliability and minimal data loss. At one point, I completely reimplemented a terribly designed module ... and got zero credit for that while the person who did the original system got promoted (I also did the re-implementation in 6 weeks, compared to the original team's 6 months). None of this was visible from the outside when I interviewed.

I've only encountered three companies that encouraged good software development (from personal experience - I've been told about good practices at other companies):

- BNR (the now-defunct Canadian equivalent of Bell Labs), with a very strong design review culture and rigorous testing

- a Canadian real estate company with ~300 offices (no longer exists) that treated its computer systems as a profit center and had an engineer as its technology VP.

- Google (although, as Dr Ousterhout points out, there is significant variability between groups) - it has good code review and tools cultures, but a somewhat weak design review culture; this is balanced by having very good people in charge of key components of its systems (Google's performance review system has a lot of false negatives, but not many false positives).

It's not enough to be a tech company -- Yahoo! had a poor software design/code/test culture when I was there (again, with large variability between groups). And Yahoo! wasn't the worst I've seen -- at one startup, some consultants held the company hostage by refusing to follow good software development practices.

While I generally agree with Dr Ousterhout that it's difficult to change an organization's style, it's not impossible. Despite my lack of management skills, I've been able to do this (at least, at a project/team level), but I introducing new ways of thinking and there was little resistance:

- code reviews (at IBM Toronto Lab and IBM Santa Teresa in the 80s)

- rigorous source code control, bug tracking, build/test cycles (at a startup in the early 90s)

- replace "waterfall" development with an iterative model (as a consultant)

As a piece of career advice - if you find yourself at odds with the company's development culture ... leave. If you're any good, there are so many opportunities out there, that it's not worth fighting to change things (you probably won't win and you'll just get stressed and bitter).

[Durant Schoon]

Thank you all for the advice and stories from the field. It sounds like there are some good suggestions to get to the goal: select companies with software as a profit center, then either join a small company already with this mindset or get into a large company where these practices are valued by some team, and then get onto that/those team(s). Thanks Greg and John for helping me set expectations about culture change and thanks Peter for some extra features of companies to filter on. I suppose I could also bring up about the book and ideas within it at an appropriate time during an interview and listen to what they say. 

If anyone knows of a particular company that uses this book as a focal point for good software development but don't want to post so publicly, feel free to send me a personal message. 

Thanks again!

[Brent Welch]

I don't know of a particular company that uses John's book, but I second the vote for Google as a great company to work for.  They have explicit motivation and rewards for good code hygiene.  

To view this discussion on the web visit https://groups.google.com/d/msgid/software-design-book/1e2c72f6-6fc4-4ed1-8898-2528d992dfcan%40googlegroups.com.

[Durant Schoon]

Thanks. Each time I apply there, I get closer to getting hired it seems :) With a family now, I'll have to see if I'm up to the challenge of preparing for interviews at that level again. It takes me a few months to get to the point where I can come up with dynamic programming solutions on the fly in real time. And oh, if you're the Brent Welch I'm thinking of, I spent about a year with your book in the mid nineties on render support at Industrial Light and Magic hacking Tcl/Tk before everyone switched to python. Thanks to you and Professor Ousterhout for some good memories!