[nine_zeros]

> Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.

Citation needed.

[RHSeeger]

This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider

- Is the client (internal, external, whatever) asking for what they really want?

- Is the client asking for what they really need?

- Am I correctly understanding what the client is asking for?

- Does building this make sense for the product as a whole?

- What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption)

- Of those As and Bs, which ones won't run into conflicts with the project

- Of those As and Bs, which ones are well supported

- Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs)

- Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability)

- How can I best use A and B in a way that is easy to understand (maintainability)

- How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability)

- and the list goes on and on and on

Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work.

Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.

[Clubber]

He's role playing the manager role in the article, hopefully sarcastically.