This is utter nonsense, it has nothing to do with being introverted, introversion != shyness, there are both introverts and extroverts that are shy, it has nothing to do with it; introversion is not a defect, fixable nor something we should want to "cure". Not being able to get useful requirements has nothing to do with being "chatty" what are you talking about?, you can talk for hours with a client and not get any useful information or you can talk 5min and get all you need, relate amount of chat with quality of requirements? really?
If you are one of these introverts, then I have bad news for you. You may end up
stuck with buggy code forever.
Why?, if you don't get the requirements right you'll have SW that doesn't meet the clients needs, not buggy code, you get buggy code if you don't write it well. If you sell Postgres as a website doesn't make Postgres "buggy".
Maybe a little less "chat" and a little more research is needed. Maybe actually talk with some fellow introverts.
I have bad news for you,
You have been talking a lot, not listening at all.
"Not being able to get useful requirements has nothing to do with being "chatty" what are you talking about?"
Are you sure about it? Don’t you think that if I as developer would be more chatty, I can get more useful requirements from client?
Maybe not ,maybe I just need more to think about their bussiness.
Also, devs need different information, not always given by the client, the client usually have no idea how the system is gonna be implemented, and are usually not interested on it. Of course it depends of the job and the situation, but in general the topics that the client knows and are interested in are not the ones related directly to devs, that's why there are steps between, not always are just bureaucracy (sometimes it is). Clients don't care if you TDD, OOP, or use X PL instead of Y; they usually don't care if you deploy with Docker or what framework you'll use, designers, sw architects, project managers, etc. Exists for a reason, should be at least, and depends of the client, the job, the size of the project, etc. But to ask devs to deal with, sales, marketing, manage the project, design the system and architecture, deploy and program is unrealistic and counter-productive
You are mostly pointing on implementation details and i agree. I also agree that developers cant do everything. But I think that developer have to heavily understand bussiness rules to do a good job. Bugs was not correct twrm i used. I meant those error when client was expecting software to work very differently than its implemented. Most of the time it is lack of precise conversations. Conversations are managed by managers and manager is maybe neccesary.
But I think that developer have to heavily understand business rules to do a good job
that's right but you have to ask yourself, so if you have 20 devs, all of them should talk to the client?, that will not be a happy client, that's why there are positions to do that, talk to the client and summarize and transform all the messy requirements that the client have, and sometimes only think they have, and rely it to the devs, that's why abstraction are vital, to implement a low level part of your code shouldn't need to know the whole system, the devs who wrote the libraries you use have no idea in what you are working on.
Clients usually have a vague at best idea of what they want/need, and with a lot of "thingies" and "stuff", to get good requirements is an art on itself, of course it could be better to devs to talk to the users, but sometimes is not an option and sometimes it would muddy the waters. In fact in my experience you don't want to increase the communication with clients, you want to improve it, a thousand meetings will likely give you a thousand new and different sets of requirements. The perfect scenario would be 1 perfect meeting where all the requirements are plainly and well defined. Also we have to respect clients time, they have their own business to deal with, not waste their time is very important.
True indeed. Now I am realizing that blog post is so personal. I am developer with smaller project. I am working alone and i am covering every technical discipline on project. Then I have a manager which one analyse client requirements and sometimes we made a miscomunicstion mistake.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is utter nonsense, it has nothing to do with being introverted, introversion != shyness, there are both introverts and extroverts that are shy, it has nothing to do with it; introversion is not a defect, fixable nor something we should want to "cure". Not being able to get useful requirements has nothing to do with being "chatty" what are you talking about?, you can talk for hours with a client and not get any useful information or you can talk 5min and get all you need, relate amount of chat with quality of requirements? really?
Why?, if you don't get the requirements right you'll have SW that doesn't meet the clients needs, not buggy code, you get buggy code if you don't write it well. If you sell Postgres as a website doesn't make Postgres "buggy".
Maybe a little less "chat" and a little more research is needed. Maybe actually talk with some fellow introverts.
You have been talking a lot, not listening at all.
"Not being able to get useful requirements has nothing to do with being "chatty" what are you talking about?"
Are you sure about it? Don’t you think that if I as developer would be more chatty, I can get more useful requirements from client?
Maybe not ,maybe I just need more to think about their bussiness.
Also, devs need different information, not always given by the client, the client usually have no idea how the system is gonna be implemented, and are usually not interested on it. Of course it depends of the job and the situation, but in general the topics that the client knows and are interested in are not the ones related directly to devs, that's why there are steps between, not always are just bureaucracy (sometimes it is). Clients don't care if you TDD, OOP, or use X PL instead of Y; they usually don't care if you deploy with Docker or what framework you'll use, designers, sw architects, project managers, etc. Exists for a reason, should be at least, and depends of the client, the job, the size of the project, etc. But to ask devs to deal with, sales, marketing, manage the project, design the system and architecture, deploy and program is unrealistic and counter-productive
You are mostly pointing on implementation details and i agree. I also agree that developers cant do everything. But I think that developer have to heavily understand bussiness rules to do a good job. Bugs was not correct twrm i used. I meant those error when client was expecting software to work very differently than its implemented. Most of the time it is lack of precise conversations. Conversations are managed by managers and manager is maybe neccesary.
that's right but you have to ask yourself, so if you have 20 devs, all of them should talk to the client?, that will not be a happy client, that's why there are positions to do that, talk to the client and summarize and transform all the messy requirements that the client have, and sometimes only think they have, and rely it to the devs, that's why abstraction are vital, to implement a low level part of your code shouldn't need to know the whole system, the devs who wrote the libraries you use have no idea in what you are working on.
Clients usually have a vague at best idea of what they want/need, and with a lot of "thingies" and "stuff", to get good requirements is an art on itself, of course it could be better to devs to talk to the users, but sometimes is not an option and sometimes it would muddy the waters. In fact in my experience you don't want to increase the communication with clients, you want to improve it, a thousand meetings will likely give you a thousand new and different sets of requirements. The perfect scenario would be 1 perfect meeting where all the requirements are plainly and well defined. Also we have to respect clients time, they have their own business to deal with, not waste their time is very important.
True indeed. Now I am realizing that blog post is so personal. I am developer with smaller project. I am working alone and i am covering every technical discipline on project. Then I have a manager which one analyse client requirements and sometimes we made a miscomunicstion mistake.