I think I understand your point. A little bit of domain expertise might be worse than none at all -- pretending to be a mediocre trader or banker, for example.
The point I meant to make is about understanding and taking an interest in business priorities. When you work for a bank or any company that isn't in the software business it's important to understand that their priorities have little or nothing to do with programming languages or technical debt or the many other things programmers obsess over. It's not that those things aren't important to programmers, but they aren't usually business priorities.
My customers rarely care what language or tools I use. Technical debt is not a big concern to them because they have short-term goals, they know the business landscape will change, and they've amortized the cost of software development and maintenance (or at least think they have). The key insight for me was understanding that "reduce shipping costs" as a business priority may have a technical side, but problems like that are rarely 100% software or technical problems, so it's important to see the entire problem and have the language to talk to people who aren't programmers to get to a solution.
I have observed my own customers sitting through presentations from developers or people selling software products and noticed, more often than not, an intense focus on technical details, but little or no interest in business priorities. Choice of programming language might be important, but it's not a business priority most of the time. Rewriting a legacy application in Rust might make sense in terms of programming and future maintenance, but may not make any sense in terms of addressing business needs. To freelance/consult successfully outside of the small niche of pure software companies you have to try to understand the actual problems and requirements, and resist the tendency programmers have to immediately reduce the problem to code.
I'm not sure I'm expressing this very well. Here on HN I see programmers posting that they just want to code in their favorite language and skip meetings and be left alone by managers and users. I see people complaining about the "stack" they have to use and writing about quitting so they can work with shinier newer things. While I like that mode too, it's not an attitude that will lead to successful freelancing/consulting, because it's too disconnected from business requirements.
Another way to look at it: software development projects generally fail or rack up big budget/schedule overruns because of misunderstanding of requirements, and miscommunication within the team and especially between the team and the business stakeholders. An example from my own experience: a brick & mortar company paid for a new e-commerce site. A week before go-live was scheduled the owner (not a technical person by any stretch) discovered that the new site did not have any provision for shipping charges or state sales taxes. She assumed the developers would know that, because any company shipping physical products has shipping costs and has to collect sales taxes. The developers blamed the customer for not spelling those requirements out. Late project, each side blaming the other, bad feelings, a potential long-term relationship spoiled. At one point in my early career I would have blamed incomplete requirements. Today I would take the customer's side -- developers selling themselves as e-commerce experts should have asked about shipping and taxes, even though those are business domain questions. My solution was to help the customer move to a SAAS e-commerce solution, which meant changing some minor parts of her business process, but kept her away from owning custom software that almost no one would want to touch in six months. I didn't get as much money from that customer as the original developers, but I'm still on speaking/consulting terms five years later whereas the original developers got sued for breach of contract.
You can think about this purely within a tech space as well.
If you are a UI designer, a little bit of knowledge about web developer can help you make UI choices which work for both the customer and for the developer.
If you as a developer know a bit about Ops, you can tweak your website design to hopefully make OPS better. Or atleast start broaching the question with your Ops girl
It happens anythime there is collaboration: knowing a little about the capabilities and constraints of the people upstream and downstream of you (suppliers and customers (perhaps internal)) helps you make better decisions or at least have better conversations etc.
Laughing because yesterday I got Photoshop proofs for some minor web site changes that failed (as usual) to take the responsive nature of web sites into account. I'm baffled why 25 years into the web designers still think the web is a kind of print medium. Not all of them -- the designers who "get" the web are the ones I refer my customers to.
Well let me just take a moment and appreciate you for what you wrote.
This is a precious comment and i totally agree with you the things you mentioned. Understanding the business problem is more important compared to what stack or programming language to choose.
It doesn’t matter if you choose python,golang or java as long as it solves the business requirements that’s all what matters and programming languages are tools but its good to choose the right tools for the job
The point I meant to make is about understanding and taking an interest in business priorities. When you work for a bank or any company that isn't in the software business it's important to understand that their priorities have little or nothing to do with programming languages or technical debt or the many other things programmers obsess over. It's not that those things aren't important to programmers, but they aren't usually business priorities.
My customers rarely care what language or tools I use. Technical debt is not a big concern to them because they have short-term goals, they know the business landscape will change, and they've amortized the cost of software development and maintenance (or at least think they have). The key insight for me was understanding that "reduce shipping costs" as a business priority may have a technical side, but problems like that are rarely 100% software or technical problems, so it's important to see the entire problem and have the language to talk to people who aren't programmers to get to a solution.
I have observed my own customers sitting through presentations from developers or people selling software products and noticed, more often than not, an intense focus on technical details, but little or no interest in business priorities. Choice of programming language might be important, but it's not a business priority most of the time. Rewriting a legacy application in Rust might make sense in terms of programming and future maintenance, but may not make any sense in terms of addressing business needs. To freelance/consult successfully outside of the small niche of pure software companies you have to try to understand the actual problems and requirements, and resist the tendency programmers have to immediately reduce the problem to code.
I'm not sure I'm expressing this very well. Here on HN I see programmers posting that they just want to code in their favorite language and skip meetings and be left alone by managers and users. I see people complaining about the "stack" they have to use and writing about quitting so they can work with shinier newer things. While I like that mode too, it's not an attitude that will lead to successful freelancing/consulting, because it's too disconnected from business requirements.
Another way to look at it: software development projects generally fail or rack up big budget/schedule overruns because of misunderstanding of requirements, and miscommunication within the team and especially between the team and the business stakeholders. An example from my own experience: a brick & mortar company paid for a new e-commerce site. A week before go-live was scheduled the owner (not a technical person by any stretch) discovered that the new site did not have any provision for shipping charges or state sales taxes. She assumed the developers would know that, because any company shipping physical products has shipping costs and has to collect sales taxes. The developers blamed the customer for not spelling those requirements out. Late project, each side blaming the other, bad feelings, a potential long-term relationship spoiled. At one point in my early career I would have blamed incomplete requirements. Today I would take the customer's side -- developers selling themselves as e-commerce experts should have asked about shipping and taxes, even though those are business domain questions. My solution was to help the customer move to a SAAS e-commerce solution, which meant changing some minor parts of her business process, but kept her away from owning custom software that almost no one would want to touch in six months. I didn't get as much money from that customer as the original developers, but I'm still on speaking/consulting terms five years later whereas the original developers got sued for breach of contract.