9 ms·

Years and lessons working at ThoughtWorks

177 points by rspivak 11y ago

mazatta 11y ago
If the author is reading this, the social sharing buttons on that page are very annoying. On my browser/resolution it covers up the first character of every line it touches, which makes reading the article without resizing the window nigh impossible.
matt_wulfeck 11y ago
> People won’t risk making mistakes if they feel they will do a bad job, lose respect from their colleagues or potentially hurt other people in that process. This such an important and overlooked aspect to learning. Also one of the best things I experienced when working for a startup. For whatever reason I found the environment much more conducive to experimentation and failure. A working POC could change the direction of a project. Most things didn't seem possible anyway, so why not try? Now at $BIGCO projects take a long time to start and are generally not full of surprises. A change in direction would probably be perceived as a negative of not thinking out your design more carefully.
AstroJetson 11y ago
Architects make the best decisions when they code In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding. Spending time with the code helps build trust, respect and a current understanding of the system. Making architectural decisions without regard for the constraints of the current system are often bad decisions. I really hate it when people don't know the difference between an architect and a tech lead. I'm happy that you gave your tech lead a title bump if that's what you want to do, but there is a difference. If you have your architects coding you are wasting time and money. Hire another programmer and have your architect do what they are supposed to.
- FordPrefectAO 11y ago
  I think the article is saying: people who are making architectural decisions (whatever their job title) should spend some time coding the system they make decisions for. It's easy enough for me to buy.
- nickpeterson 11y ago
  Honestly, many people that are architects can't code. Forcing them to code on the project helps save organizations from trusting important architectural decisions to people who simply are not or never were developers. Also it helps teams work together if the person often creating work for developers understands exactly what he's asking them to do.
- umanwizard 11y ago
  Titles and job roles vary enough across the industry that I'm pretty sure there isn't a canonical, obviously correct meaning to things like "architect".
  - AstroJetson 11y ago
    I agree that job descriptions can vary. The article says "Architects make the best decisions when they code" and then goes on about having "tech leads" code. In a startup the CIO / CTO can be coders (they may be the other partner in a 2 person company). But in a company that is 12 years old, they should be at the point that they have high level/high talent people doing those jobs. So I would expect that they have a CEO that runs the company and a CIO that runs IT and architects that do systems / application architecture. Not spending a day and a half each week cranking out code.
    - nilliams 11y ago
      The argument I imagine (and that I agree with) is that if you aren't in touch with the code you begin to lose touch (esp. in this fast-moving industry) and you become an ivory-towered twit that your teammates can't relate to and begin to resent. I am a fairly experienced JS dev and I can't imagine retiring to a hands-off architect role in that world, because there are so many tool choices and options in terms of programming style (even languages that compile to JS), so I feel like I need to be regularly writing 'app code' to know how to advise my teammates well. Saying 'though shalt write TypeScript and use these libraries, and these OOP practices, and structure your app in this way' would feel fairly obnoxious if I wasn't working with the team, with those technologies to write actual code myself. If my teammates instead wanted to do functional programming in Elm, and all I could offer was hypotheticals as to why that was a bad idea, I really wouldn't expect my teammate's respect, and would expect them to be quite-rightly put-out.
      - AstroJetson 11y ago
        There is a difference between the two. As an architect you would need to keep up with what the different tool sets (compilers, transpilers, frameworks, database interfaces, etc, ) and what's going on in those spaces. Understand why your currently chosen toolset is working and where their roadmap is and how well your company is on that roadmap. Whats the new universe of tool in your space, is one of them going to help you? Is it something you should pilot/plan for, keep an eye on or ignore? You need to focus on that and figure that out. Having you work on tickets or new features isn't the best use of your time. Working out how it all works (and works well) together and where the holes are is your prime function. Let's talk about the "Thou shalt". That's when you lead the education process. Why AstroScript is the way, what it will do, how it will work, how it scales, etc. You get some level of buyin and once that's done the team rocks and rolls in that effort. You want to help out with the first set of features fine, but once they get going let them go and get out of their way. You then look for the next thing down the road. Hey your team wants to do Elm? Is that in the plan, have all the little nuances been looked at, does it scale, etc. etc. Yes, then go that way. No? Then it's up to you to either close the gaps with Elm or put the ship back on track. That's what architects do. I understand people ending up as "white board architects". They suck, they happen. You can be "hands on", be an advisory, be a resource, be involved with the team. But you shouldn't be cutting daily code. Lastly, I want to repeat that the original article is about a company that is 12 years old. Well past a few developers, a company that wants and should be on a growth path. Scout around and look at some Y successes that are $100+ million companies. Track their architect(s) down and ask what they do. If they are spending 30% of their time doing app-dev write back to me. Happy to treat you to dinner anywhere in Philly.
- jacques_chester 11y ago
  I think the concept of software architects as a kind of Supreme Leader, distinct from team, is a legacy of waterfall. A project fails. It is an expensive failure. Fingers are pointed. Lessons are "learned". "Never again!" is the cry. A new project is authorised. More effort is put into the front of the project, because that's what the classic software engineering literature says you must do to avoid costly failures. The budget is bigger, but that's OK, because it's being spent on requirements analysis and some architects to Make Sure It Goes Right This Time. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised. Even more effort is put into the front end. Even more money. "This time we're going to hire Senior Architects!". Firms that used to be accountancies, but have now discovered the lucrative value of having interns move boxes in Visio while billing out the Senior Architect for $800/hr, are called in to help. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised ...
- lbarrow 11y ago
  Do you really think software architects shouldn't write code? It's very very important that someone designing the system in the large understand how it actually works day to day, and writing code is an effective way to do that.
- maxxxxx 11y ago
  I work a lot with architects in our IT department and I have had that title before. In my view an architect that doesn't keep coding will be outdated within a few years and most of them know that they are not really needed. Coming up with an architecture should be fairly easy for experienced senior developers if allowed to do so. Actually implementing it and adapting the architecture to real-world problems is the hard part.
- dasil003 11y ago
  Maybe you should enlighten us then. An architect who doesn't code to me is redundant. And BTW, I say this as a developer with 20 years experience who has turned CTO as my company approached 50 employees. I am extremely capable of thinking through architecture level decisions, and it is my prerogative to declare myself chief architect and fulfill that role if I wish. The only problem is, as someone who is writing very little code these days, it would be extremely foolish for me to dictate architecture down to my senior engineers. To me, "Architect" has become an anachronism, it dates from a time when programming experience was thin on the ground, and languages were very low level, requiring a lot of bit twiddling and optimization to be viable. Under those circumstances, it makes more sense to have someone laying things out without writing any code. These days, I just don't see the point.
jph 11y ago
ThoughtWorks hired me this month. The culture is excellent and matches up with these 12 lessons. I'd add a 13th lesson about combining individual empowerment with teamwork. If you're interested in working with ThoughtWorks, I'm happy to help and connect you with the right contacts. Email joelparkerhenderson@thoughtworks.com.
- MrBuddyCasino 11y ago
  Are they still traveling a lot at TW? I don't want to live in a hotel for 4 days a week, so I declined when they approached me.
  - Garbage 11y ago
    Well, traveling really depends on project. But you can actually ask for non-travel project. I would recommend talking to the recruiter and let them know your preferences before declining.
    - MrBuddyCasino 11y ago
      > you can actually ask for non-travel project Interesting, thanks. At my current job they try to staff local as much as possible, there is no formal hierarchy and we also have 20% time, so my standards are high. Traveling too much would be a no go for me.
  - jph 11y ago
    Travel like that is your choice and is based on what projects you want to do. Generally speaking, the travel is because the client wants the team to be on site and pairing with the client's people. We have a bunch of people who prefer not to travel as much, and that's fine too. Also, work-from-anywhere tooling is getting better and better, and more of our clients are asking about it. In my opinion these tools are really good though not as good (yet) as being in person in groups.
- e12e 11y ago
  I'd actually be interested to know what thoughtworks does, and how (much) I could (should/would) pay for whatever services thoughtworks provides... I looked at https://www.thoughtworks.com/products https://www.thoughtworks.com/products etc - and I still don't know what thoughtworks provides, or how much what it costs? Am I just looking in the wrong place?
henrik_w 11y ago
I love reading "lessons learned" type posts. The ones I like best here are: #5 Architects make the best decisions when they code. Amen. #10 Appreciate that everyone has different strengths - that's how a team becomes more than its parts. Here are my lessons learned from 25 years of SW development: http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ http://henrikwarne.com/2015/04/16/lessons-learned-in-softwar...
- tootie 11y ago
  Architects coding can be a challenge. I try to write code as often as I can, but I usually don't want to actually take ownership of dev tasks because I usually can't complete them quickly enough with all the demands on my time. Usually in the middle phase of a project when the architecture is set, we've delivered a few sprints and launch is still a little ways away is a good time to dive in for a bit.
  - Swannie 11y ago
    I agree. Even when its not coding, I try to take on a technical part of the delivery for myself, particularly a tricky integration that I've got the best knowledge on, or most suitable background to solve. However, like you, I find that I'm often pulled away, and if I invest the time time make what I'm doing of a high quality (walk the talk), I'm typically neglecting higher value tasks. The biggest challenge I have is managers who know you get on the tools, who turn around at crunch time and expect you to dive in and fix issues. Sorry but whilst I am indeed an expert troubleshooter, because I know the architecture, and designed to minimise a lot of these issues, I'm not usually the best person to foresee the impact of my fixes, and again, due to wanting to set a solid example, I don't want to do a hack to fix it, so it takes a quite a long time... when I should be triaging, providing troubleshooting insight, and considering any architectural changes that make whole classes of problems less impacting.
- aswanson 11y ago
  Those lessons are golden. I've picked them all up along the way, but its worthwhile to verbalize them consciously every few weeks.
dominotw 11y ago
I worked at place where they had multiple vendors work on the same project, client prbly din't want get locked in with one vendor. Thoughtworks was one of the implementors and I was with another vendor. Thoughtworks had 'agile coaches' on the team who would dictate process and alienate anyone who wasn't from thoughtworks, only thoughtworks employees had access to their 'mingle' project planner where they would do all the planning. One of the main objectives of these 'agile coaches/architects' was to make sure they lock down this big client for future projects by integrating themselves deeply into clients processes and alienating everyone else. Their commercial products like mingle are explicitly designed with this in mind. Their 'take over' phase also involved binging in lots of young consultants who would work really long hours, most of them on my project were fresh college graduates from their bangalore/pune office bought overseas on L1 visas who work 12-14 hr days. Anyone who questions them would be labeled not 'agile' enough and by extension a liability to the project. I left the project shortly because it was not my battle to fight. Employees who worked there associated agile with consulting company scam. It was disappointing to see agile methodology being coopted by consulting companies for their own ulterior motives. Thoughtworks was just another consulting company who uses 'agile' to out maneuver their competitors. I always wondered why thoughtworks is considered to be different from other companies in the class like accenture/ibm. I've never used a product or opensource project made by Thoughtworks. This was about 7-8 yrs ago so things might be different now, not sure if they still doing their agile stickh.
- Spearchucker 11y ago
  "...so things might be different now..." Nope, that's still the status quo. I have workd alongside them on and off for the better part of 10 years now, last time a year ago, and this happens every time on multi-vendor projects. I struggle most with pair programming - it is divisive. That said, also last year, I worked with a guy from Thoughtworks who had real issues with stand-ups. Too much ceremoney, he said. I hoped at the time it was a bit of reality setting in, but not sure how far-reaching that is.
- xorcist 11y ago
  Interesting you should say that. I've recently cleaned up a big install of their Go product. What struck was the massive NIH-ness of it the product. I wondered if it mirrored the organization behind it. (And if you want to avoid the complexities of the likes of Jenkins, do yourself a favor and whip up a Python script instead. It'll look the same after a few years anyway.)
mangeletti 11y ago
I worked with some ThoughtWorks consultants a few years ago, and I would say the author here is probably a diamond in the rough. This was a very good read. ThoughtWorks needs to read this and particularly heed point #9. The primary goal of theirs during our month—or so—long consultation seemed to be to force a team of 40+ developers down a rigid and dogmatic path of TDD. They also advocated pair programming, but a lot of us (I'm extrapolating "a lot" from the unanimity of the few I was close to and talked to about this) felt like they were really just winging it; like they were apprentice developers barely learning the concepts of TDD and pair programming at the same time they were charging to purportedly teach us. It was a frustrating and fruitless endeavor that taught our team basically one thing; don't work with ThoughtWorks again.
- davidrupp 11y ago
  Ex-ThoughtWorker here. Pat is indeed a respected voice in this space, even amongst ThoughtWorkers, but he is not the only diamond. I learned pair programming and TDD from many colleagues over three years and four major projects. In all that time, there was exactly one individual whom I thought was a waste of space. On the whole, ThoughtWorks' typical approach to agile (note: lower-case 'a') development is firmly grounded in the pragmatics of what used to be called Extreme Programming, not Scrum-type dogma. I'm sorry you had a bad experience in your brief engagement with TW. I believe it to be atypical, and I hope you'll have occasion to reconsider your -- not un-dogmatic -- conclusion.
- solarengineer 11y ago
  Pat is indeed a diamond, though there are plenty others to keep him company. As for your experiences with ThoughtWorkers, do bear in mind that at the end of the day, everyone is a human who could make mistakes. It appears from your experience note that the month-long engagement could have been structured better.
- plinkplonk 11y ago
  (Due Disclosure: Ex ThoughtWorker) Pat is certainly very sharp and thinks deeply about issues. So are many other ThoughtWorkers, he is not alone. But otoh, TW also has a minority of dogmatic agile/TDD etc people for whom such practices are close to religion and any other approach is blasphemy. It seems you might have run across some of them. The best way for a client to use ThoughtWorks is to get their team to work on a chunk of software, keep them from switching taleted developers out for more junior folks, and add a couple of client devs to that team for a few months at a time. This ensures high quality and osmosis of practices without the kind of high pressure conversion tactics you seem to have experienced. ThoughtWorks is a great company and has many talented and thoughtful devs, but if you are paying them you have to pay attention to how they work and not let a few bad apples run amok and destroy your team morale. Just my 2 cents.
nvarsj 11y ago
Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict. Ugh, such a false dichotomy. Does anyone actually think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is a good idea? Instead, compare to any one of hundreds of successful examples on github, all using feature branch based models. Thoughtworks (and other consultancies that take the CD book to heart) would have everyone pair programming and committing directly to master. This simply doesn't scale beyond a small team. It also actively discourages collaboration across teams, because there is no process in place to review external contributions.
- nilliams 11y ago
  I don't quite understand your comment, are you saying you are for-or-against feature branches? Your 2nd paragraph seems to be saying you dislike the git-flow model, but the 3rd suggests you like feature branching? Anyway to add my 2c, we use hg-flow at work (git-flow for Mercurial), and it works well for us, because all our repos have a consistent feel to a new dev approaching them -- the 'develop/release/hotfix' streams convey a lot of meaning about the repo's state. Though I should point out we are a small team (<10 active devs), and rarely do we encounter bad merges when we finish our feature branches. However I've listened to a few good podcasts lately about trunk based development [0] [1] and can see the advantages for large teams (as it forces people to deal with merges sooner, and keep code shippable, instead of deferring them to some nasty, big, future merge). [0] https://devchat.tv/iphreaks/136-ips-efficient-engineering-practices-for-software-projects-with-neal-ford https://devchat.tv/iphreaks/136-ips-efficient-engineering-pr... [1] http://theshipshow.com/2013/09/branching-merging-and-octopi-oh-my/ http://theshipshow.com/2013/09/branching-merging-and-octopi-...
- madeofpalk 11y ago
  It's about long-lived branch-based development which defers feedback. That's what's dangerous. I don't think OP is claiming that all branches are evil.
- 11y ago
zik 11y ago
> Everyone can be a leader. This seems like a naive point of view. In any real organisation people naturally form hierarchies, even if they're implicit and unstated. It's just human nature. Then if someone lower in the hierarchy starts to suddenly act like a leader they'll have other people who are notionally higher than them in the hierarchy stomp on them, quelling the usurper initiative in order to maintain their own position in the social hierarchy. This is such a deep part of human nature that people don't even know they're doing it. It's well documented in psychology texts but for some reason people deny it happens in their own workplace. Yet I've observed it happening in every workplace I've ever been in.
- draw_down 11y ago
  Yep, I agree. In pretty much every organization I've worked in, some engineers are more equal than others. If you're a golden child, you'll have praise heaped upon you for whatever you do. If you're not one of them, you can take charge and go above & beyond if you want... but probably no one will care. So at least for me, I really question the value of doing those things nowadays. I just do my work, try hard to do a good job, help out if I'm asked, and that's that. The worst aspect of this dynamic is when you see one of the "more equal" people doing something that's going to cause pain and trouble down the road, but you know nobody is gonna listen. That's life as an engineer I guess.
- edwinnathaniel 11y ago
  Perhaps both of you and the author are half-right? :) This is his statement: > People can demonstrate acts of leadership regardless of their title and can do so in many different ways, simply by taking action on something without the explicit expectation or request for it. A simple example of what he's saying would be a person driving a change. Some of us, developers, probably have been in a not-so-great situation (e.g.: build takes too long, culture of not writing unit-tests/automation-tests, etc) and occasionally there's this one passionate individual that starts a movement slowly but sure in order to change the situation to a better one. I think that's what he's saying. What you're saying is probably akin to someone lower in the rank starts telling everybody including his/her supervisor/leads how to do their job properly in order to fix the situation... :D
deleted 11y ago
[deleted]
otaviokzuk 11y ago
I believe TW can be a great experience for many devs. But hey, don't trust posts of their own people on the matter. This is a company where it's standard practice for big wigs to post not only technical content, but also "evangelising" stuff to attract other employees. Read glassdoor reviews from current/ex employees and check how it feels for you. Some people love it to the point of religious fervour, while other hate it as if it murdered their mom savagely. So make sure it looks right for you before applying for a job there.

177 points by rspivak 11y ago

If the author is reading this, the social sharing buttons on that page are very annoying. On my browser/resolution it covers up the first character of every line it touches, which makes reading the article without resizing the window nigh impossible.

matt_wulfeck 11y ago

> People won’t risk making mistakes if they feel they will do a bad job, lose respect from their colleagues or potentially hurt other people in that process. This such an important and overlooked aspect to learning. Also one of the best things I experienced when working for a startup. For whatever reason I found the environment much more conducive to experimentation and failure. A working POC could change the direction of a project. Most things didn't seem possible anyway, so why not try? Now at $BIGCO projects take a long time to start and are generally not full of surprises. A change in direction would probably be perceived as a negative of not thinking out your design more carefully.

AstroJetson 11y ago

Architects make the best decisions when they code In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding. Spending time with the code helps build trust, respect and a current understanding of the system. Making architectural decisions without regard for the constraints of the current system are often bad decisions. I really hate it when people don't know the difference between an architect and a tech lead. I'm happy that you gave your tech lead a title bump if that's what you want to do, but there is a difference. If you have your architects coding you are wasting time and money. Hire another programmer and have your architect do what they are supposed to.

FordPrefectAO 11y ago
I think the article is saying: people who are making architectural decisions (whatever their job title) should spend some time coding the system they make decisions for. It's easy enough for me to buy.
nickpeterson 11y ago
Honestly, many people that are architects can't code. Forcing them to code on the project helps save organizations from trusting important architectural decisions to people who simply are not or never were developers. Also it helps teams work together if the person often creating work for developers understands exactly what he's asking them to do.
umanwizard 11y ago
Titles and job roles vary enough across the industry that I'm pretty sure there isn't a canonical, obviously correct meaning to things like "architect".
- AstroJetson 11y ago
  I agree that job descriptions can vary. The article says "Architects make the best decisions when they code" and then goes on about having "tech leads" code. In a startup the CIO / CTO can be coders (they may be the other partner in a 2 person company). But in a company that is 12 years old, they should be at the point that they have high level/high talent people doing those jobs. So I would expect that they have a CEO that runs the company and a CIO that runs IT and architects that do systems / application architecture. Not spending a day and a half each week cranking out code.
  - nilliams 11y ago
    The argument I imagine (and that I agree with) is that if you aren't in touch with the code you begin to lose touch (esp. in this fast-moving industry) and you become an ivory-towered twit that your teammates can't relate to and begin to resent. I am a fairly experienced JS dev and I can't imagine retiring to a hands-off architect role in that world, because there are so many tool choices and options in terms of programming style (even languages that compile to JS), so I feel like I need to be regularly writing 'app code' to know how to advise my teammates well. Saying 'though shalt write TypeScript and use these libraries, and these OOP practices, and structure your app in this way' would feel fairly obnoxious if I wasn't working with the team, with those technologies to write actual code myself. If my teammates instead wanted to do functional programming in Elm, and all I could offer was hypotheticals as to why that was a bad idea, I really wouldn't expect my teammate's respect, and would expect them to be quite-rightly put-out.
    - AstroJetson 11y ago
      There is a difference between the two. As an architect you would need to keep up with what the different tool sets (compilers, transpilers, frameworks, database interfaces, etc, ) and what's going on in those spaces. Understand why your currently chosen toolset is working and where their roadmap is and how well your company is on that roadmap. Whats the new universe of tool in your space, is one of them going to help you? Is it something you should pilot/plan for, keep an eye on or ignore? You need to focus on that and figure that out. Having you work on tickets or new features isn't the best use of your time. Working out how it all works (and works well) together and where the holes are is your prime function. Let's talk about the "Thou shalt". That's when you lead the education process. Why AstroScript is the way, what it will do, how it will work, how it scales, etc. You get some level of buyin and once that's done the team rocks and rolls in that effort. You want to help out with the first set of features fine, but once they get going let them go and get out of their way. You then look for the next thing down the road. Hey your team wants to do Elm? Is that in the plan, have all the little nuances been looked at, does it scale, etc. etc. Yes, then go that way. No? Then it's up to you to either close the gaps with Elm or put the ship back on track. That's what architects do. I understand people ending up as "white board architects". They suck, they happen. You can be "hands on", be an advisory, be a resource, be involved with the team. But you shouldn't be cutting daily code. Lastly, I want to repeat that the original article is about a company that is 12 years old. Well past a few developers, a company that wants and should be on a growth path. Scout around and look at some Y successes that are $100+ million companies. Track their architect(s) down and ask what they do. If they are spending 30% of their time doing app-dev write back to me. Happy to treat you to dinner anywhere in Philly.
jacques_chester 11y ago
I think the concept of software architects as a kind of Supreme Leader, distinct from team, is a legacy of waterfall. A project fails. It is an expensive failure. Fingers are pointed. Lessons are "learned". "Never again!" is the cry. A new project is authorised. More effort is put into the front of the project, because that's what the classic software engineering literature says you must do to avoid costly failures. The budget is bigger, but that's OK, because it's being spent on requirements analysis and some architects to Make Sure It Goes Right This Time. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised. Even more effort is put into the front end. Even more money. "This time we're going to hire Senior Architects!". Firms that used to be accountancies, but have now discovered the lucrative value of having interns move boxes in Visio while billing out the Senior Architect for $800/hr, are called in to help. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised ...
lbarrow 11y ago
Do you really think software architects shouldn't write code? It's very very important that someone designing the system in the large understand how it actually works day to day, and writing code is an effective way to do that.
maxxxxx 11y ago
I work a lot with architects in our IT department and I have had that title before. In my view an architect that doesn't keep coding will be outdated within a few years and most of them know that they are not really needed. Coming up with an architecture should be fairly easy for experienced senior developers if allowed to do so. Actually implementing it and adapting the architecture to real-world problems is the hard part.
dasil003 11y ago
Maybe you should enlighten us then. An architect who doesn't code to me is redundant. And BTW, I say this as a developer with 20 years experience who has turned CTO as my company approached 50 employees. I am extremely capable of thinking through architecture level decisions, and it is my prerogative to declare myself chief architect and fulfill that role if I wish. The only problem is, as someone who is writing very little code these days, it would be extremely foolish for me to dictate architecture down to my senior engineers. To me, "Architect" has become an anachronism, it dates from a time when programming experience was thin on the ground, and languages were very low level, requiring a lot of bit twiddling and optimization to be viable. Under those circumstances, it makes more sense to have someone laying things out without writing any code. These days, I just don't see the point.

jph 11y ago

ThoughtWorks hired me this month. The culture is excellent and matches up with these 12 lessons. I'd add a 13th lesson about combining individual empowerment with teamwork. If you're interested in working with ThoughtWorks, I'm happy to help and connect you with the right contacts. Email joelparkerhenderson@thoughtworks.com.

MrBuddyCasino 11y ago
Are they still traveling a lot at TW? I don't want to live in a hotel for 4 days a week, so I declined when they approached me.
- Garbage 11y ago
  Well, traveling really depends on project. But you can actually ask for non-travel project. I would recommend talking to the recruiter and let them know your preferences before declining.
  - MrBuddyCasino 11y ago
    > you can actually ask for non-travel project Interesting, thanks. At my current job they try to staff local as much as possible, there is no formal hierarchy and we also have 20% time, so my standards are high. Traveling too much would be a no go for me.
- jph 11y ago
  Travel like that is your choice and is based on what projects you want to do. Generally speaking, the travel is because the client wants the team to be on site and pairing with the client's people. We have a bunch of people who prefer not to travel as much, and that's fine too. Also, work-from-anywhere tooling is getting better and better, and more of our clients are asking about it. In my opinion these tools are really good though not as good (yet) as being in person in groups.
e12e 11y ago
I'd actually be interested to know what thoughtworks does, and how (much) I could (should/would) pay for whatever services thoughtworks provides... I looked at https://www.thoughtworks.com/products https://www.thoughtworks.com/products etc - and I still don't know what thoughtworks provides, or how much what it costs? Am I just looking in the wrong place?

henrik_w 11y ago

I love reading "lessons learned" type posts. The ones I like best here are: #5 Architects make the best decisions when they code. Amen. #10 Appreciate that everyone has different strengths - that's how a team becomes more than its parts. Here are my lessons learned from 25 years of SW development: http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ http://henrikwarne.com/2015/04/16/lessons-learned-in-softwar...

tootie 11y ago
Architects coding can be a challenge. I try to write code as often as I can, but I usually don't want to actually take ownership of dev tasks because I usually can't complete them quickly enough with all the demands on my time. Usually in the middle phase of a project when the architecture is set, we've delivered a few sprints and launch is still a little ways away is a good time to dive in for a bit.
- Swannie 11y ago
  I agree. Even when its not coding, I try to take on a technical part of the delivery for myself, particularly a tricky integration that I've got the best knowledge on, or most suitable background to solve. However, like you, I find that I'm often pulled away, and if I invest the time time make what I'm doing of a high quality (walk the talk), I'm typically neglecting higher value tasks. The biggest challenge I have is managers who know you get on the tools, who turn around at crunch time and expect you to dive in and fix issues. Sorry but whilst I am indeed an expert troubleshooter, because I know the architecture, and designed to minimise a lot of these issues, I'm not usually the best person to foresee the impact of my fixes, and again, due to wanting to set a solid example, I don't want to do a hack to fix it, so it takes a quite a long time... when I should be triaging, providing troubleshooting insight, and considering any architectural changes that make whole classes of problems less impacting.
aswanson 11y ago
Those lessons are golden. I've picked them all up along the way, but its worthwhile to verbalize them consciously every few weeks.

dominotw 11y ago

I worked at place where they had multiple vendors work on the same project, client prbly din't want get locked in with one vendor. Thoughtworks was one of the implementors and I was with another vendor. Thoughtworks had 'agile coaches' on the team who would dictate process and alienate anyone who wasn't from thoughtworks, only thoughtworks employees had access to their 'mingle' project planner where they would do all the planning. One of the main objectives of these 'agile coaches/architects' was to make sure they lock down this big client for future projects by integrating themselves deeply into clients processes and alienating everyone else. Their commercial products like mingle are explicitly designed with this in mind. Their 'take over' phase also involved binging in lots of young consultants who would work really long hours, most of them on my project were fresh college graduates from their bangalore/pune office bought overseas on L1 visas who work 12-14 hr days. Anyone who questions them would be labeled not 'agile' enough and by extension a liability to the project. I left the project shortly because it was not my battle to fight. Employees who worked there associated agile with consulting company scam. It was disappointing to see agile methodology being coopted by consulting companies for their own ulterior motives. Thoughtworks was just another consulting company who uses 'agile' to out maneuver their competitors. I always wondered why thoughtworks is considered to be different from other companies in the class like accenture/ibm. I've never used a product or opensource project made by Thoughtworks. This was about 7-8 yrs ago so things might be different now, not sure if they still doing their agile stickh.

Spearchucker 11y ago
"...so things might be different now..." Nope, that's still the status quo. I have workd alongside them on and off for the better part of 10 years now, last time a year ago, and this happens every time on multi-vendor projects. I struggle most with pair programming - it is divisive. That said, also last year, I worked with a guy from Thoughtworks who had real issues with stand-ups. Too much ceremoney, he said. I hoped at the time it was a bit of reality setting in, but not sure how far-reaching that is.
xorcist 11y ago
Interesting you should say that. I've recently cleaned up a big install of their Go product. What struck was the massive NIH-ness of it the product. I wondered if it mirrored the organization behind it. (And if you want to avoid the complexities of the likes of Jenkins, do yourself a favor and whip up a Python script instead. It'll look the same after a few years anyway.)

mangeletti 11y ago

I worked with some ThoughtWorks consultants a few years ago, and I would say the author here is probably a diamond in the rough. This was a very good read. ThoughtWorks needs to read this and particularly heed point #9. The primary goal of theirs during our month—or so—long consultation seemed to be to force a team of 40+ developers down a rigid and dogmatic path of TDD. They also advocated pair programming, but a lot of us (I'm extrapolating "a lot" from the unanimity of the few I was close to and talked to about this) felt like they were really just winging it; like they were apprentice developers barely learning the concepts of TDD and pair programming at the same time they were charging to purportedly teach us. It was a frustrating and fruitless endeavor that taught our team basically one thing; don't work with ThoughtWorks again.

davidrupp 11y ago
Ex-ThoughtWorker here. Pat is indeed a respected voice in this space, even amongst ThoughtWorkers, but he is not the only diamond. I learned pair programming and TDD from many colleagues over three years and four major projects. In all that time, there was exactly one individual whom I thought was a waste of space. On the whole, ThoughtWorks' typical approach to agile (note: lower-case 'a') development is firmly grounded in the pragmatics of what used to be called Extreme Programming, not Scrum-type dogma. I'm sorry you had a bad experience in your brief engagement with TW. I believe it to be atypical, and I hope you'll have occasion to reconsider your -- not un-dogmatic -- conclusion.
solarengineer 11y ago
Pat is indeed a diamond, though there are plenty others to keep him company. As for your experiences with ThoughtWorkers, do bear in mind that at the end of the day, everyone is a human who could make mistakes. It appears from your experience note that the month-long engagement could have been structured better.
plinkplonk 11y ago
(Due Disclosure: Ex ThoughtWorker) Pat is certainly very sharp and thinks deeply about issues. So are many other ThoughtWorkers, he is not alone. But otoh, TW also has a minority of dogmatic agile/TDD etc people for whom such practices are close to religion and any other approach is blasphemy. It seems you might have run across some of them. The best way for a client to use ThoughtWorks is to get their team to work on a chunk of software, keep them from switching taleted developers out for more junior folks, and add a couple of client devs to that team for a few months at a time. This ensures high quality and osmosis of practices without the kind of high pressure conversion tactics you seem to have experienced. ThoughtWorks is a great company and has many talented and thoughtful devs, but if you are paying them you have to pay attention to how they work and not let a few bad apples run amok and destroy your team morale. Just my 2 cents.

nvarsj 11y ago

Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict. Ugh, such a false dichotomy. Does anyone actually think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is a good idea? Instead, compare to any one of hundreds of successful examples on github, all using feature branch based models. Thoughtworks (and other consultancies that take the CD book to heart) would have everyone pair programming and committing directly to master. This simply doesn't scale beyond a small team. It also actively discourages collaboration across teams, because there is no process in place to review external contributions.

nilliams 11y ago
I don't quite understand your comment, are you saying you are for-or-against feature branches? Your 2nd paragraph seems to be saying you dislike the git-flow model, but the 3rd suggests you like feature branching? Anyway to add my 2c, we use hg-flow at work (git-flow for Mercurial), and it works well for us, because all our repos have a consistent feel to a new dev approaching them -- the 'develop/release/hotfix' streams convey a lot of meaning about the repo's state. Though I should point out we are a small team (<10 active devs), and rarely do we encounter bad merges when we finish our feature branches. However I've listened to a few good podcasts lately about trunk based development [0] [1] and can see the advantages for large teams (as it forces people to deal with merges sooner, and keep code shippable, instead of deferring them to some nasty, big, future merge). [0] https://devchat.tv/iphreaks/136-ips-efficient-engineering-practices-for-software-projects-with-neal-ford https://devchat.tv/iphreaks/136-ips-efficient-engineering-pr... [1] http://theshipshow.com/2013/09/branching-merging-and-octopi-oh-my/ http://theshipshow.com/2013/09/branching-merging-and-octopi-...
madeofpalk 11y ago
It's about long-lived branch-based development which defers feedback. That's what's dangerous. I don't think OP is claiming that all branches are evil.
11y ago

zik 11y ago

> Everyone can be a leader. This seems like a naive point of view. In any real organisation people naturally form hierarchies, even if they're implicit and unstated. It's just human nature. Then if someone lower in the hierarchy starts to suddenly act like a leader they'll have other people who are notionally higher than them in the hierarchy stomp on them, quelling the usurper initiative in order to maintain their own position in the social hierarchy. This is such a deep part of human nature that people don't even know they're doing it. It's well documented in psychology texts but for some reason people deny it happens in their own workplace. Yet I've observed it happening in every workplace I've ever been in.

draw_down 11y ago
Yep, I agree. In pretty much every organization I've worked in, some engineers are more equal than others. If you're a golden child, you'll have praise heaped upon you for whatever you do. If you're not one of them, you can take charge and go above & beyond if you want... but probably no one will care. So at least for me, I really question the value of doing those things nowadays. I just do my work, try hard to do a good job, help out if I'm asked, and that's that. The worst aspect of this dynamic is when you see one of the "more equal" people doing something that's going to cause pain and trouble down the road, but you know nobody is gonna listen. That's life as an engineer I guess.
edwinnathaniel 11y ago
Perhaps both of you and the author are half-right? :) This is his statement: > People can demonstrate acts of leadership regardless of their title and can do so in many different ways, simply by taking action on something without the explicit expectation or request for it. A simple example of what he's saying would be a person driving a change. Some of us, developers, probably have been in a not-so-great situation (e.g.: build takes too long, culture of not writing unit-tests/automation-tests, etc) and occasionally there's this one passionate individual that starts a movement slowly but sure in order to change the situation to a better one. I think that's what he's saying. What you're saying is probably akin to someone lower in the rank starts telling everybody including his/her supervisor/leads how to do their job properly in order to fix the situation... :D

deleted 11y ago

[deleted]

otaviokzuk 11y ago

I believe TW can be a great experience for many devs. But hey, don't trust posts of their own people on the matter. This is a company where it's standard practice for big wigs to post not only technical content, but also "evangelising" stuff to attract other employees. Read glassdoor reviews from current/ex employees and check how it feels for you. Some people love it to the point of religious fervour, while other hate it as if it murdered their mom savagely. So make sure it looks right for you before applying for a job there.