we had one of the most productive working relationships I've ever had
Finding a dynamic like this is a treasure.
My version of it was working with someone who had an inclination to solve all problems on the "algorithmic level" so to speak. Every time we worked on a feature, no matter how big, he would start with the hard CS problems and never really leave that head space. I thought of it as a "bottom up" approach. I on the other hand always took the "top down" approach and focused most of my efforts on APIs and architecture.
In his view, if you don't correctly solve the "real problem" (the hard CS problem) then everything else will fall part. If you base your architecture on the wrong solution then your layers of abstraction won't make any sense.
In my view, you should take the naive approach with the CS problem and focus mostly on the interface and system level architecture. If the interface and architecture are a mess, your application is going to be a buggy mess everywhere else too (death by a thousand cuts).
At first working together was so painful! We argued about everything. Worse, we'd be arguing about completely different things because our points of view were so different!
As soon as we recognized our differences we became a well oiled machine. A new project came in, he focused in on the CS problem, I focused on the architecture, and we'd (usually painlessly) merge our solutions.
The balance was even useful when we worked on separate projects. I knew that if I had a very narrow complex problem
then I could come to him for a brilliant solution. He knew that if he got stuck trying to design a system with lots of moving parts that I'd offer a solid robust and fault tolerant systems level solution.
Comments
Finding a dynamic like this is a treasure.
My version of it was working with someone who had an inclination to solve all problems on the "algorithmic level" so to speak. Every time we worked on a feature, no matter how big, he would start with the hard CS problems and never really leave that head space. I thought of it as a "bottom up" approach. I on the other hand always took the "top down" approach and focused most of my efforts on APIs and architecture.
In his view, if you don't correctly solve the "real problem" (the hard CS problem) then everything else will fall part. If you base your architecture on the wrong solution then your layers of abstraction won't make any sense.
In my view, you should take the naive approach with the CS problem and focus mostly on the interface and system level architecture. If the interface and architecture are a mess, your application is going to be a buggy mess everywhere else too (death by a thousand cuts).
At first working together was so painful! We argued about everything. Worse, we'd be arguing about completely different things because our points of view were so different!
As soon as we recognized our differences we became a well oiled machine. A new project came in, he focused in on the CS problem, I focused on the architecture, and we'd (usually painlessly) merge our solutions.
The balance was even useful when we worked on separate projects. I knew that if I had a very narrow complex problem then I could come to him for a brilliant solution. He knew that if he got stuck trying to design a system with lots of moving parts that I'd offer a solid robust and fault tolerant systems level solution.
Ah, I miss it.
Industry rarely requires solving hard CS problems, can you share what kind did you guys encounter?Most of the times its APIs and database calls, iirc.