4 ms·
An excellent point! It reminds me of how drafting was thoroughly disrupted by AutoCAD: https://rarehistoricalphotos.com/life-before-autocad-1950-1980/ https://
by disqard 3y ago
An excellent point! It reminds me of how drafting was thoroughly disrupted by AutoCAD:
https://rarehistoricalphotos.com/life-before-autocad-1950-1980/ https://rarehistoricalphotos.com/life-before-autocad-1950-19...
How much of (our, as in, programmers') work is the "writing code" part, vs. all of the other stuff? Build consensus, gather feedback, communicate ideas, resolve ambiguities, make non-zero progress in the absence of clear direction, etc.
- ska 3y ago> How much of (our, as in, programmers') work is the "writing code" part, In my experience, For a junior/entry level, 80%+ For a (actual, not just title) Sr. dev? Typically <= 20-25%.
- nradov 3y agoThere's no way that even juniors are spending as much as 80% of time actually writing code. They spend >20% attending meetings, completing mandatory training, reading user stories, participating in code reviews, waiting for test execution, etc.
- ska 3y agoThat's highly dependent on scale of org, but fair enough. Sometimes it's closer to 60. And sometimes your seniors are only seeing 10-15, for the same reason.
- didntknowya 3y agoidk it'll closer to 60% coding, of which >50% would be looking thing up rather than actually writing anything
- kragen 3y agohttps://skeptics.stackexchange.com/questions/17224/do-professional-software-developers-write-an-average-of-10-lines-of-code-per-day https://skeptics.stackexchange.com/questions/17224/do-profes... 10–20 lines of code per day means the “writing code” part is about 2 minutes out of an 8-hour day, if you only count the code that ends up being delivered. maybe 10× that including unit tests, drafts that get replaced, duplicate code that gets refactored away, test code to see what a library will do, etc. but ai can obviously handle a lot of that stuff too
- jacobr1 3y agoThis is why I've never really understood the focus on optimizing typing speed in IDEs with shortcuts and similar things. It just isn't a bottleneck I've ever faced. I do understand the desire to customize one's own tools, and optimize things for its own sake ... but I don't get the thought process that proclaims this as some source of meaningful productivity improvement.
- deafpolygon 3y agoI'll take a tool like Visual Studio or Netbeans over (n)vim any day. A standardized way of working is sometimes better because if I have to work with someone- then it helps to be able to work on the same thing together. Tools like Visual Studio, Microsoft Office, even Netbeans or Eclipse allow us to converge on a highly productive but standardize working environment that we can work from. If I'm running off a highly customized setup, and my partner is also doing the same thing - then I am only functional at my own workstation and nowhere else.
- gaganyaan 3y agoOTOH those all have different keybindings, but just about everything has vim keybindings available somehow. I've found it useful to learn vim keybindings because of that. I actually use them for emacs via evil.
- deafpolygon 3y agoHow often are you working in Eclipse AND Visual Studio on the same project? If you're working in an IDE, it's pretty useful to have the standard keybindings. You may have standard vim bindings mostly to manipulate text. But there are bindings in other IDEs to find next definition/declaration of the function under the cursor, debugging, refactoring, and so on. Within the same IDE, you will find most people don't customize those. At least, in my experience, anyways.
- jacobr1 3y agoA long time ago, I switched from emacs to vim, because I switched to a company that used Sun Solaris in production, and it didn't have emacs and ssh'ing into boxes was common need. They didn't have vim, either, just vi.