What makes programmers really productive: requirements, not tools!

And what are the starting point of the proper requirements? Two experts negotiating between two domains. The client can be anything: iron foundry scheduling, van customization, church accounting. And you should be the expert negotiating to the limits of what you can produce technically with your tools and experience. (For example, you don't negotiate a mobile app if you are only an expert in web front ends, though I have had some managers do this). That balancing of tools and goals starts even before the codified requirements are agreed upon.

So from the very start, just constructing proper requirements is already a balance. Yes, you will need to expand your knowledge on day 1 of the client's domain, but all of this is negotiated from the perspective that you are (and will remain) the expert in the technical domain. Because you've chosen to use familiar tools, you have that time and opportunity to expand your knowledge of the client's foreign domain at the start of the project.

In your scheduling program, it may be critical to learn that the consequences of low quality dog-biscuit testing means delaying the day's first iron pour and calling back the mold makers to the foundry. You have the time to find out these quirks at the start of the project by getting into the client's domain.

While all that is new to you, you're trading off the time that you need to stay on top of your domain for learning the client's. Sure, the pace of tech development is slow and, as the expert, you have a window that you can completely block out following the changes in your own domain. But how long is that window? A week? A month? 3 months? Maybe just touch base here and there? There are times that checking on the developments in your domain is going to be trivial, and times with major new tech changes that won't be. (An iOS developer after WWDC, for example.)

How many development shops give programmers time to educate themselves on the tools they use? "Hey Joe, take a couple of weeks off here to experiment with the hot, new Javascript frameworks before we bring you back to work on this new high paying client's project." Most expect you to maintain your domain knowledge on the job (or in your spare time), or you'll be disposed of for new talent that has kept up with the tools.

If you're making a career of being a technical expert in a domain, your personal priority is staying an expert in that domain. For a particular project, you can certainly spend time learning a client's domain and requirements, but you'll never be an expert in iron foundry scheduling (or whatever) so your priority should always be to fulfill that project without losing your expertise in your domain. Again, it's always a balancing act.

/r/programming Thread Parent Link - marcobehler.com