A few years ago in my previous company there was a major push to convert a lot of the codebase to Python. A byproduct of this conversion was an easier way to build UI using predefined widgets. Yet no one was using this functionality due to the mindset of years of TCL. I honestly hated TCL.
So I took it upon myself to explore the entire new code base and go about building UI panels. Initially I just couldn't understand how the code mapped out until one day I just printed out some of the code and read it repeatedly till it made sense.
The whole exercise was an eye opener.
Nobody's just reading your code
181–188 of 188 posts
Re: Nobody's just reading your code
#182Earlier quoted context omitted.
I sometimes wonder what fully-honest Scrum would look like. I mean... 3 points: dealing with ticketing system. 5 points: looking into bugs/issues which will become new tickets. 5 points: taking questions and talking process on other people's tickets. The list goes on. I like agile, and I don't hate Scrum, but it's unpleasantly easy to end up running a planning/scheduling process which is completely distinct from one'…
Tickets based development can not work very well. We need tickets (hell, I have to write them for myself on personal projects, otherwise I get locked), but we need something else too. I also wonder how we can formalize that something else - time-boxing it is harmful, full attention to it is harmful, having to explain it too much is harmful.
I have a strong suspicion that the reason points and time-boxing are so bad is that they're trying to weld two distinct processes together.
Tickets are great; they bound tasks, provide a clearinghouse for all relevant information on an issue, and help monitor and prioritize needed work.
The instinct to turn the "what work exists at what priority?" tool into a "let's organize our work" tool is totally understandable given all that, but I think it's a serious mistake. Tickets define tasks, but their times are highly variable (timeboxing is ugly, storypointed "investigation" tickets are uglier) and they exclude a whole bunch of non-ticket work: communication, bureaucracy, unstructured inspection, and so on.
If you make tickets the basic unit of scheduling, you're suddenly building "buffer" tickets and padding ticket durations to account for "something always comes up". It's Goodhart's law in action; your metric - storypoints - becomes a target and stops being an accurate metric.
Re: Nobody's just reading your code
#183I read code to learn all the time. And I don’t get paid to program.
Re: Nobody's just reading your code
#184Reading code just for fun was a thing in the early and mid years of UNIX (eg., 7th edition or System V). People eagerly passed around faint 10th generation photocopies of Lion's printout of and commentary[1] on the UNIX source code. The annual USENIX conference had a popular short course in which they went through the entire UNIX kernel line by line. Why was that a thing back then and not now? Certainly UNIX was an a…
I'm a younger developer and I had never heard of Lions' Commentary. It sounds amazing and I'll order a copy, but is there a more updated version or a similar book out there that may be more relevant?
Re: Nobody's just reading your code
#185Earlier quoted context omitted.
This is still done today, just with other software. I've read blog posts that go through the entire redux javascript library line by line, or review an entire chunk of React. Even just yesterday here on HN was a submission that just contained shaders from Wolfenstein.
There's a category of articles out there nowadays that do "$library in $num lines of code", reducing popular libraries or frameworks down to their core - filtering out all the edge cases, so to speak. I've seen them for Angular, React, Redux, etc. I think that a lot of frameworks and libraries would do good to have a "core" codebase somewhere, something pure but unoptimized and without edge cases that are easily dige…
Do you mind linking me to the React one? I was unable to find it, but maybe my Google-fu is just not good today.
Re: Nobody's just reading your code
#186Earlier quoted context omitted.
"...open a PR offering to fix it..." Perhaps I've been asking to wrong people (at the wrong time) - forgive me - but (as dar as I can tell) git has no easy / reasonable way to repo'tize a (vendor/) dependency. That means you have to bend over backwards (read: make too much extra effort) to patch such a library local and then eventually PR that change. This feels like a fairly significant flaw in the current OSS "ecos…
Use git submodules. git submodules interact tolerably neatly with GitHub's PR functionality; if you make changes to your submodule, then it's straightforward to turn that into a PR that you can submit to the upstream repo. And since your updates are a git branch like any other, if the upstream repo won't accept your changes then you can just keep doing fetch+merge/rebase to keep on top of the changes at their end. Of…
Yes. But I've occasionally seen situations where vendor is not gitignore'd. It's tracked like everything else. Submodules doesn't help then.
Thanks.
Re: Nobody's just reading your code
#187Earlier quoted context omitted.
Use git submodules. git submodules interact tolerably neatly with GitHub's PR functionality; if you make changes to your submodule, then it's straightforward to turn that into a PR that you can submit to the upstream repo. And since your updates are a git branch like any other, if the upstream repo won't accept your changes then you can just keep doing fetch+merge/rebase to keep on top of the changes at their end. Of…
Yes. But I've occasionally seen situations where vendor is not gitignore'd. It's tracked like everything else. Submodules doesn't help then. Thanks.
Assuming I've understood correctly, if you want the easy workflow then you just have to have the 3rd party code in its own repo and add that repo as a submodule. Best if that repo is one you look after, so that you can commit local changes to it if you like.
If you've not done this from day one, and you've got changes made to the 3rd party code, that's a bit of a pain, but provided you tracked (or can figure out) the version you were working from you can solve this manually. It's a bit of donkey work though.
(You have to decide from the start whether you're going to just put each dependency in the repo, or whether you're going to keep each dependency as its own submodule. I do think git works a lot better if you keep each 3rd party dependency as its own submodule: easier to patch your repo's copy, easy to make PR from your patches, easier to keep your patches merged in on top of later updates, and so on. But you have to plan for this a bit, and I won't deny that the submodule UX is pretty awful.)
Re: Nobody's just reading your code
#188Earlier quoted context omitted.
I have only been coding for 1.5 years and this kind of comment is validating what I worry is a very bad habit. I hate using dependencies unless they have reached a certain level of legend in the community.
> ...unless they have reached a certain level of legend That is a similar tactic I use now for anything core. I know I commented that we don't have any dependencies in our core systems, but as an afterthought, this isn't entirely accurate. We do, but as you said they are "legendary", and don't change a whole lot anymore. I think you are on the right track. :) Edit: Keep business practicality in mind, if using a 3rd p…
Some of this conversation isn't as exclusive and the tone it has.
Many of these dependancies are open source. Nothing prevents you from copy/pasting the code and then maintaining it yourself. Then you alleviate the "hard to change" problem and you can vet it thoroughly inside your own team.