> #5 Architects make the best decisions when they code.
It's not just a matter of coding, it's about the right kind of coding.
I like to have architects be pareto-programmers, that is they get to 80% of of the solution so that they can hand off the rest to a less-experienced team member. They can solve the hard part of the problem without getting stuck making it productionized and provide an opportunity for mentoring.
There's two other code related tasks that are important: code reviews and commit reviews. They give views at different "heights". We have fairly good tooling around the former; I'd love a tool that gave me an email every morning that had X number of random commits distributed over the total committers as best as possible while showing me who hasn't committed for a while.
As a team member, pareto programmers are the worst. They do all the fun interesting work, then raise their hands and push the important work on the team. They refusw to take ownership of their features, create a mess for you to clean up because they certainly missed a detail or two, and just generally suck to work with.
The worst is when they say "This is your code man. I'm just helping you out a bit."
No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.
I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When concerns were raised during pull request reviews, the inevitable answer was "not gonna change it -- approve it now because my sprint is in danger".
If an obviously junior developer is given an obviously 'fun, interesting' task, they should pair with a developer or have frequent reviews so any problems are caught before pull request stage. You need to catch these sorts of things before you get so late in the stage.
Additionally, you need a structure and culture that is able to hold back pull requests if the code is bad - that's the whole point of code review!
You just hand them fun, interesting work that doesn't do too much damage to the company when it fails. In practice, this means that your most senior people end up doing work that is very interesting, yet very arcane.
I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable.
The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.
I guess architects as pareto-programmers is great from a business side since it hopefully means things get done faster as the 'difficult' work can be done by the most experienced programmer(s).
Unfortunately, to work, the team under the architect needs to want these hand-outs. I'd wager that a lot of developers do not want to be simply told what to do or to clean-up and make it production ready.
In the end, I think a pareto-programmer architect selects for a team that simply does what it's told and that leads to a situation where no one will question the architect and that leads to bad code.
Yes this is exactly what happens in my experience. I've recently gotten rid of both architects on the application I work on. The programmers you want on your team are the ones who feel empowered by thinking for themselves and owning the solutions they come up with.
Hence why I am always cautious when getting architecture tasks.
Behind the name Architects, you get lots of different understandings depending on the organization.
I have seen in being used as technical architects, business architects, solution architect, application architects. Usually only technical architects tend to mean some kind of coding, with the other ones being synonyms for some sort of manager.
So I always feel I need to describe what I understand for architecture role, to make sure everyone is on the same page.
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.
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.
An age old rule for managers. You can't manage or treat everyone the same. Certain people respond to certain things. That's why great managers are able to really pull the best work out of their employees. They know what drives each one of them.
My definition of Architecture (from another commenter): making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable.
I spend the vast majority of my time on "architecture" (as opposed to coding) making it so that it's trivial to track down problems in production, trivial to identify the cause once you do, and trivial to deploy the solution once you've made the fix.
If you do architecture right, most fixes end up being the moral (if not literal) equivalent of one-liners. At least, that's been my experience.
Do architecture wrong (or worse: not at all) and you end up having to rewrite and/or redesign your code entirely, just to identify and/or fix bugs (i.e. not even adding new features).
Says every architect ever. Hifalutin words. So what, we build in 'flexibility' - guessing which way we plan on going in a year or two. Then in 6 months we pivot, and find we didn't anticipate that direction.
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.
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.
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.
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.
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.
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.
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.
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 etc - and I still don't know what thoughtworks provides, or how much what it costs? Am I just looking in the wrong place?
ThoughtWorks does custom software consulting, and specializes in high-throughput projects.
For example suppose you're Acme Widgets, and you want to build a web app, mobile app, analytics, a data lake, real-time stream processing, and all the continuous delivery tooling to go with this.
You can hire ThoughtWorks to provide the team to build all this and also teach your own people how to do it. The pay is essentially the same as you'd pay hiring your own employees for the project, i.e. time and materials.
The advantage of hiring ThoughtWorks is when you want a team of people who all know how to work together, and you want the team for a specific project goal.
An example that may be useful for the Hacker News readers: suppose you work for a San Francisco startup, and you want to ship a product fast, and do validated learning something like the Lean Startup book, or Steve Blank's Business Model Canvas. You can have your own employees building the core product, and you can hire a ThoughtWorks team to build your client apps, continuous delivery pipelines, analytics dashboards, and the like.
With having some products, ThoughtWorks does consulting and custom software development (services) as well.
ThoughtWorks has developed Mingle - a project management tool, Go - a continuous delivery tool, Snap - a continuous delivery tool on cloud, Gauge - test automation tool.
But you can also hire ThoughtWorks for consulting on agile organization transformation, programming practices, etc. If you are looking for teams to help you develop custom software with these practices, ThoughtWorks can help you with that as well.
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.
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.
What is your definition of "small"? The projects I worked on at ThoughtWorks for over three years numbered in the dozens of developers, all pairing, and all committing directly to master.
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).
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.
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.
Atleast two signatories if Agile Manifest has stated that the movement has lost its way [1][2].
I think it never had a chance. With the old waterfall model, projcet managers had some power : they could continuosly interrupt engineers and ask them to do more and more since project went in one trajectory for years. They were justified since the engineers had plenty of 'downtime'. Engineers had some power, the project never changed direction and they could work out the design and implement it carefully, managing technical risk.
When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. I suspect this delicate balance of power was created, not out of a sense of fairness, but for efficiency. But when the people in power saw this they said : 'I will take these parts of the methodology that are useful to me and ignore these parts that are not useful'. Cue the 50 point stories, sprint abortions, mid-sprint story additions etc. Question the reasoning and you are labelled anti-agile. I suppose this was the only way it could go.
" Engineers had some power, the project never changed direction and they could work out the design and implement it carefully, managing technical risk."
I've seen the opposite more often: Many a waterfall had poor assumptions made up front without a lot of technical risk management afterwards beyond "helicopter parenting" from architects.
Most successful agile teams I run into, engineers hold most if not all of the power to design and implement - the product owner wields ultimate power over function and priority.
"When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. "
That's Scrum's approach. Modern XP Shops I've tended to see adopt iterationless approaches, where there is a retro and planning session every week or so, but not really to recognize "iterations" per se. Features are delivered when they're delivered, deployments and releases are automated so they can happen whenever the product owner wants.
Biggest point of success, however is to eliminate project management as we usually know it. There's a product owner, and a product manager and they are usually an empowered customer paired with someone that knows how to build "products", ie. A focus on learning and testing rather than the certainty demanded of most projects. Project managers become at best glue players that protect the team from organizational antibodies.
>Atleast two signatories if Agile Manifest has stated that the movement has lost its way [1][2].
At one of the clients I was working at, they bought in Martin Fowler to the site, who was being touted as one of the 'inventors' of agile methodology. Agile was being sold as a silver bullet and thoughtworks the deliverer of the software nirvana.
the irony of
"Individuals and interactions over processes and tools"
was not lost on anyone.
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.
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.)
You should do some research. Go came from a product called Cruise, which in itself came from Cruise control. Search that name and you will know which tool came first and who was behind it. (Link just in case - https://en.m.wikipedia.org/wiki/CruiseControl )
Definitely not NIH. Many new tools in CI/CD space clearly acknowledge Go as the one of the first tools in the pipelines and CD area. While ConcourseCI looks good, even Jenkins 2.0 cannot compare to the first class pipelines support in Go.
I wouldn't have jobs fixing these installations if I hadn't worked in this area for a while. I used Cruise Control and lived to see it crushed under the dominance of Hudson/Jenkins. And Go bears very little resemblance to it. A classic second system, if you will. It's like how every new tool throws out everything old, aiming for a complete rewrite, but several years later is still a web interface where you enter shell commands. The opportunities for these to develop .. intricacies are endless.
If you think Go was the first tool in the CD area, that probably says more about Thoughtworks defining CD as whatever-we-say-it-is, rather that the capabilities of a specific tool. It's not that people didn't do CD before 2010. It didn't bring anything new at the time. I suspect Go would have fared better if it was a Jenkins visualization plugin, there it could have ridden the coattails of its DSL system. Jenkins is the PHP of CI/CD and you need to go above and beyond it if you want to replace it. I would love, for example, to see Ansible/Red Hat bring their automation experience to this space. Imagine a CD Tower plugin, or a build system where not just the dependecies are declarative. I haven't had the opportunity to use Concourse yet, but I'm sure I will.
I lived through the nightmare of cruise control. Kudos to Thoughtworks for writing it as it was the first CI tool, and then actual thanks to JetBrains for writing Team City so we could actually make sense of our builds!
> 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.
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.
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.
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
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.
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.
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.
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".
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".
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.
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.
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.
What are your lessons learned on how Architects should keep up (and avoid becoming whiteboard architects)?
My personal realization is that it is necessary to be hands on to understand new technology rather than just reading up documentation and others' opinions on such technology.
Actually this is good for any architect. The ability to achieve consensus across all the groups gets you the buy-in that you need. It also ferrets out the detractors that are going to spend the next decade throwing rocks at the decision.
Next is go make friends with the operations people. Learn how operations works and what they do, how they monitor, how they keep things running. While they appear to be BOFH like, when they get the idea that you are listening to them, they will help you out. Make sure someone from OPS is on your consensus team. I had a white board architect (WBA) work for me and I made him get signature approval from OPS on everything he proposed. After awhile he got it and became less of a WBA.
Do lots of proof of concepts to see if what you are thinking about will work. In the past I've had a cadre of co-ops / interns do the grunt work. They are always excited about working with a new technology.
(If you are in the Philly Area, call Drexel University. You can get co-op students year round in either 3 or 6 month increments. Pro tip: Don't hire them until after they graduate. If you don't send the co-op back to the University so the Uni can get the rest of their money, they will stop sending you co-ops. )
The other advantage of co-ops is that you can afford to go down some dead ends. It's a win-win, you use a less expensive resource to find out bad news, the co-op gets to put "Worked on Astroscript at major company" on their resume. It's very freeing because you can then take on someone from the outside going "Hey lets do Elm", assign an co-op to do most of the grunt work rather than burning your time up.
You can be as hands on as you want. I've always found that getting some new tool installed is a huge mess. Need this library and that version of something else, these scripts don't work, etc. So my co-ops do that. Once it's spun up and running and their first mini-Proof Of Concept is working then I'll get involved with a larger POC and get my hands dirty.
(An aside on the install mess. When we get ready to start the "Moving to Astroscript" to the internal consensus cycle, I assign a co-op to package it. They put together a clean setup process for both Operations and the Dev Manager to sign off. Nothing kills a project faster than the people you want approval from not being able to spin it up to look at it.)
It's mostly lots and lots of talking to people about what their pain points are, what direction the business is going in, thinking about planned and unplanned pivots, etc. Always be thinking about a Plan B.
My check list for new things (in order)
* What business value does this bring (ROI)
* How does operations run this
* What is the Disaster Recovery Plan
* What is the opportunity cost
* What is the internal friction
* What is the external friction with our partners
Other things that may help:
Start a series of brown bag sessions (your call if the bags contain lunch or beer) and present out to anyone what you are thinking about. ( Tip: Master the ability to create a 50 minute long Powerpoint in 30 minutes. )
Talk to other architects / users that are using the tools, designs, etc. and see what they are finding out. Be ready to share back what you find. "Hey our review and POC of Astroscript figured out that getting any useful logging out of it was impossible, so we are punting"
Be a nice person. And remember, someday you may end up working for one of those co-ops.
I've found it is easy to avoid white board architects:
Dont give them any actual authority.
If they want to drive architecture in a certain direction then they have to convince the senior developers, project managers, and tech leads to follow them.
As someone who works with a bunch of architects who don't code, I'd really rather not. It's basically a one way road to not being current, which in theory shouldn't matter, but in reality it very much seems it does.
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.
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.
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.
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.
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.
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-softwar...