What makes a good professional what he is is not how good is his knowledge in developing a piece of software, not even how clever, intelligent or talented he is. It’s how fast he is developing a well designed and precisely structured project. That is something close to what is mentioned here, companies rushing after time and not quality. Only without the “not quality” part.
It is really important what is the time frame a product is delivered. When talking about software development it is most important to predict certain behavior of the code you’ll be creating and decide whether that is the right direction or something that at some point would go down as house of cards. When estimating one should know the specifics of the final product what it does and how it please the user. But knowing software features and functionalities and applying your knowledge on developing them is only 2/3 of what an estimation should be about.
Developers should put extra development time into solving what we’ll name ‘small screwups’. And that is something unpredicted, setting proper width of a View, doing precise input validation or creating simple animations that would enhance the UI/UX of the application. That way the developer will not be manipulated by his imperfection of designing good architecture at so many levels and instances. He will not be cheated by the general perspective of the final product and yes, the general overview of a product is lying to us. It says “Ah, I need to do a application that would do this and that”, understating the processes behind, the systems, libraries and concepts needed to be implemented. The developer will be able to handle all those small screwups if there is enough time to do so. And there will be time to do so if the developer is done with developing after 2/3 of the estimated development time. Otherwise the software he creates would be just another average buggy product.
It is pretty similar like when I look at an airplane from the airport and see its massive aluminium-built structure with powerful engines and seats. What I can think at first, ignoring the small screwups factor, is that creating something out of aluminium can be quite easy. Putting engines on it also (well ok, just trying to explain my point). Seats and cabin equipment would not be a problem also, all I need is money to buy all these parts (which is a non-technical reason for not building an airplane). But does the fact that i have created a bicycle by myself or being able to dismantle and assemble my car by myself proves that I am also able to create an airplane? If I see the rough image, yes. Otherwise I will fail at the point when I will have to connect plane’s toilet signs with the logics whether the toilet door is locked or not.
Same goes with development of any other product. People make general impression of the idea and are hunted by developing that impression. When the time is coming closer to the deadline and that impression is about to be finished, developers may find themselves in a situation where they’ll have to refactor most of what they have created. What is the cure for this sickness? Just ask lots of questions. Ask whether that color is gray or slate gray, if the line is 2px or 2.5px in width. Take apart every small module and feature of the project by dismantling the project and let the process of assembling those parts be the process of the development.
There aren’t perfect professionals. Every once in a while we come to a situation where we need to redo things, replan activities, refactor code and erase what we’ve written previously. And that should not be demotivating unless it’s not part of a process of improvement and going ahead. Small screwups will always be there.