Using 3rd party software and libraries: spend hours flicking through documentation pages to find lots and lots of information, but no clarity.
Developers spend most of their time figuring the system out
11–20 of 418 posts
Re: Developers spend most of their time figuring the system out
#12Figuring out existing bespoke systems is what sucked the joy of programming out of my soul.
Re: Developers spend most of their time figuring the system out
#13Relevant to this article is Peter Naur's paper on Programming as Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and…
See also Bill Thurston's commentary on the nature of mathematical knowledge:
"mathematical understanding does not expand in a monotone direction. Our understanding frequently deteriorates as well. There are several obvious mechanisms of decay. The experts in a subject retire and die, or simply move on to other subjects and forget. Mathematics is commonly explained and recorded in symbolic and concrete forms that are easy to communicate, rather than in conceptual forms that are easy to understand once communicated. Translation in the direction conceptual -> concrete and symbolic is much easier than translation in the reverse direction, and symbolic forms often replaces the conceptual forms of understanding. And mathematical conventions and taken-for-granted knowledge change, so older texts may become hard to understand.
In short, mathematics only exists in a living community of mathematicians that spreads understanding and breaths life into ideas both old and new."
https://mathoverflow.net/questions/43690/whats-a-mathematici...
Re: Developers spend most of their time figuring the system out
#14I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..
And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.
Re: Developers spend most of their time figuring the system out
#15I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..
I feel like if there's good documentation, you don't need me. Similarly, the best leverage I can have is improving documentation or making documentation unnecessary through better interfaces.
Re: Developers spend most of their time figuring the system out
#16Relevant to this article is Peter Naur's paper on Programming as Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and…
A former colleague sent me an receipt that had an error from a system we worked on years ago (2 and 3 companies ago respectively). I bet we could tell the current devs where to find the bug pretty easily as we wrote a lot of that code.
Re: Developers spend most of their time figuring the system out
#17I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..
I feel like if there's good documentation, you don't need me. Similarly, the best leverage I can have is improving documentation or making documentation unnecessary through better interfaces.
> Similarly, the best leverage I can have is improving documentation or making documentation unnecessary through better interfaces.
I used to be a big fan of doco and still am. But a founder once told me that it is better to have intuitive UX (which obviates the need for documentation) and that rang true.
Re: Developers spend most of their time figuring the system out
#18I spend about 60% of my non-meeting time fighting with broken tooling that was supposed to make my life easier.
Re: Developers spend most of their time figuring the system out
#19People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying. Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of times faster than screwing around by yourself. Pointed-haired bosses and accountants will never understand this. If you pair and rotate, the inexperienced person becomes experienced quickly, and it's viral if you also do rotating pairing. A team with one expert and pairing is now a team full of experts.
Re: Developers spend most of their time figuring the system out
#20Haha, so true! I've found that for most systems, there are three great ways to "figure it out". * Start from input. (Browser, API, whatever starts a process.) Map from there. * Start from data storage. (Database, flat files, whatever.) How does state get persisted? * How does the system move into production? If you can make a small change (even adding an innocuous comment) and see it all the way from your machine to…
A couple of things I found helpful along those lines:
* Data storage: what does the schema look like? Even if it is not persisted to a relational DB, is it possible to draw out a schema of a data model and all the relationships ("JOINS")
* Add logging to code you are trying to debug but are hard to understand and repro bugs for in production. Once you have logs about the full state that reproduces the error, the issue will be easier to fix. Don't roll out a fix before fully understanding an issue. As a corollary to this: always add a task to remove this verbose logging you added once the bug is fixed!