Remember, technology will make your life easier.
I am on phone with support bc new laptop will turn itself on from hibernate (and even shutdown but I suspect that was windows update foobar).
I hate windows, I just have too many tools I don’t want to run under wine and also linux on laptop hardware is no joke or at least used to be…
My usual answer is “ThinkPad”.
Have you used Windows Subsystem for Linux? It’s really good (in my opinion). At least, it makes one Windows machine equal to what used to be one Windows machine plus an ssh session to a Linux machine. No more wine/cygwin. Though the terminal isn’t amazing, but it’s improving. (Windows Terminal, that is)
WSL makes Windows a lot more bearable. But it is not a substitute. A lot of things are really difficult to run via the WSL f.e. Docker has been causing a lot of trouble at work recently (with the windows docker client licensing changes they had to switch over). I only discovered WindowsTerminal at the new work but yes, that is a good start. Windows has improved but I still miss the possibilities and clear cut configurations of my linux development days. (Linux has always caused me tons of trouble, too, just when you had found the cause you knew you had fixed it. With Windows I am never sure. I may or may not have fixed this now with the new chipset driver…)
my irony detector just crashed
I was asleep, early for once, when my work phone buzzed. I am not oncall, so it shouldn’t. It was a place called “hotboys “ telling “Eric “ his “order” was ready. I was a little hesitant to Google hotboys, but it appears to be a chain of chicken restaurants in California.
Great, now I’m going to be awake at night wondering if Eric ever found out that his chicken was ready
I was writing an RPG adventure and it turned into a software development project.
There hasn’t been Acrobat Reader for Linux for A While, and it was riddled with holes even then.
However, it turns out that Lee has added a JSON export; and Chaosium recently released a set of PDF form-fillable character sheets.
At which point I believe the term is “Ka-Perl!”, and now I have proper autogenerated PDF character sheets of my CoC characters.
For about half an hour or 45 minutes of our wait at the emergency room on Monday, my husband kept getting texts and one phone call update on something I can’t remember now. A car being worked on, a scheduled furniture delivery, I don’t know but something big you’d leave your cell number for. Definitely not anything we were actually doing since all we cared about at the time was the CT scan results that would confirm his appendicitis and it wasn’t that.
No idea why this passage from the excellent Last Chance to See by Douglas Adams makes me think of you, Roger…
I’ve just spent a cheerful hour of my time writing a program on my computer that will tell me instantly what the volume of the [megapode] mound was. It’s a very neat and sexy program with all sorts of pop-up menus and things, and the advantage of doing it the way I have is that on any future occasion on which I need to know the volume of a megapode nest, given it’s basic dimensions, my computer will give me the answer in less than a second. The downside, I suppose, is that I cannot conceive of any future occasion that I am likely to need to know the volume of a megapode nest, but no matter: the volume of this particular nest is a little over nine cubic yards.
What the mound is is an automatic incubator. The heat generated by the chemical reactions of the rotting vegetation keeps the eggs that are buried deep inside it warm - and not merely warm. By judicious additions and subtractions of material from the mound the megapode is able to keep it at the precise temperature which the eggs require in order to incubate it properly.
So all the megapode has to do to incubate the eggs is to dig three cubic yards of earth out of the ground, fill it with three cubic yards of rotting vegetation, collect a further six cubic yards of vegetation, build it into a mound, and then continually monitor the heat it is producing and run about adding bits or taking bits away.
And thus it saves itself all the bother of sitting on its eggs from time to time.
A sysadmin is someone who will spend a day automating a boring five-minute monthly task.
While I spent the last two days working with someone on actual code which is cool. What irritates me that we obviously code in English and all variables are named in English but the domain language is German and all the concepts are named and documented in German and comments are in German and so German creeps into the code and we need to remember all the time that Untertitel are Subtitles in code and all of that just costs unnecessary thinking power. Meh.
But still: code! The two of us are spending a week for what will amount to a couple hundred lines of code. And it is only that much because UI is involved. The actual code code is maybe 30 lines. Still, code. And in a project that has 1000s of lines and 100s of classes we only took 1 day to find where to put those lines.
Do you do pair programming as a regular thing, or is it because you’re new to the project? I’m curious because we have a recurring discussion about whether to use pair programming, TDD, pair testing, etc. But somehow nothing ever changes…
It could be worse - at least they’re two distinct language. Meanwhile, I have to remember that things like CSS properties are in American English (so I have to use color and center) despite content being in British English.
Or the quirks of localisation: eg the one site we built that’s for an American audience, so any plugins we make for it will need to reflect that. Which wouldn’t matter much if “enrol/enrolment” weren’t a common term used throughout the site (yay for e-learning!).
Currently we‘re even using the „Code with me“ feature of IntelliJ to program in the same IDE. But this is very much due to 2 factors: remote work being the biggie and me being new to the project as the second one.
However, I do think it is absolutely worth doing more often than I used to.
The team does a pretty well executed Scrum process. Today was refinement day—with the product owner talking about the new feature that is going to be the focus in the next product increment and us having to make a few estimates for recent tickets that made it into the backlog and were deemed important enough to need estimates now.
So my assumption is and I heard them talk about it that they do pair programming on a semi-regular basis.
For example we really spent a day talking and just analyzing the code (my coding partner is also a bit „new“ to the project, he has been there for only a year, don‘t laugh it is a big project). We ended up with 4 classes we had to touch for the first Durchstich (I really don‘t remember the English term for that and cannot find a translation, it means more or less an initial attempt to get something up and running). I have rarely had such a controlled coding session and such quick success. It may be due to the fact that I have not programmed anything for about 2 years and so I needed to think everything through better because I couldn‘t afford to just go off and „try“ as I usually would. It may be because with two of us we had to debate our ideas before implementing anything. And with two people one is usually thinking of the stuff the other forgets. I would say we were faster together than we would have been dividing the task and going off on our own.
Being with someone in a video call for so many hours is a bit stressful though. Luckily, our personalities seem to mesh well enough (either that or he‘s being very courteous and patient with me) or it wouldn‘t work.
As for TDD. The extreme form as written out in the book is BS in my not so humble opinion. It is a good theory and it shows a process that one can use: on occasion.
Only what we call „Grüne Wiese Projekt“ (a fresh one without any history) can ever aspire to do follow TDD to the letter and I bet you my copy of Spirit Island that within N sprints—where N is a small single digit number—there will be either so much technical debt that the devs give up or they will stumble across something that just doesn‘t lend itself to unit testing like remote systems, databases, UIs and you can only mock everything for so long until you are no longer really testing your project but just making a farce of testing for the sake of TDD.
I absolutely aspire to write clean, well-tested code and I think having a good test coverage is crucial to being able to work in these environments. With horror have I looked at some of the classes I encountered and I had to struggle to import the settings for the code inspections from a colleague because the defaults from the IDE would present me with hundreds of warnings from some classes (and some of those warnings really were unnecessary and some are debatable—I am always on the side of being more strict I like the compiler to find my errors for me not the runtime environment—but there were enough warnings to give a developer nightmares… including design issues.
But yeah, there‘s this saying „das ist hysterisch gewachsen“ („this grew hysterically“ as a wordplay on historically) when we want to excuse the amount of technical debt in a project and this project has it in spades. The saving grace being their scrum process I believe. If not for that it would not be possible to work on this.
There are a lot of different tests in the project
- some unit tests
- some integration tests
- some UI tests
- there are three stages of systems (dev—test—production)
- there is a test team (though the dev team complained that the test team hasn‘t been working well even after having several meetings of being briefed on the new features)
So to conclude this, I think just like pair programming, TDD is a tool one can use on occasion especially when encountering the rare case of complicated code (as opposed to complicated structures).
Prototype? Minimimal viable feature (or product)?
My experience with team programming is that it works well at showing a new person the code base or maybe a new language. I’m not fond of it for real productive work, but it does work for some people.
I also don’t like most of agile, and am very glad I work for an extreme anti-agile shop (we just write software, we don’t like to talk about it). My last job was sort of agile (we took the bits that worked for us, which were focused sprints, cost estimating on tickets, and a daily scrum, more or less), and I found lots of it very limiting. (I found it very hard to implement long term stuff. I had lots of features that were more than a sprints worth of work, it was difficult to say “give me a month, and I’ll come back with that module”, even though I had a track record of that, and the one time I was give free reign (and a budget for a couple contractors) we came back with scheduler improvements that were way better than I’d promised. (roughly: I said it would it would be twice as fast on a given set of workload, and would work at all on a workload that caused the existing scheduler to blow up. We came back running the blow up work load about an order of magnitude faster than than existing scheduler did the smaller one, and doing the smaller set three or four orders of magnitude faster (it was hard to get numbers, because the UI became the limiting factor).
TDD was what made that project possible, we had a suite of ~2k integration tests, and showing that our fork passed the ones that mattered (a whole lot of them turned out to be testing behavior that wasn’t actually a requirement, but were things that if they were borked in the old scheduler something else was wrong) and was faster at them, was a big key in getting buy in for the project and for when it was time to merge it into the trunk.
That seems to fit. It is a German translation of some term from agile development. But I cannot figure out what the original is. I am sure it is something catchy but not in the dictionary.
I am not sure we’re talking about the same thing when we say TDD. TDD by the book is means you write the tests first—before any code exists. That is what I think does not work most of the time. Having written tests in the past and then refactoring or rewriting part of the code is great obviously.
As for agile development: it is a big change. It was for me. Personally, I very much appreciate it. It helps distribute and channel the workload and gives a lot of transparency to the whole process that helps both the chickens and the pigs (sry classic agile metaphor for those who don‘t know—the chickens aka stakeholders only have to lay eggs, while the pig aka devs have to provide the bacon. I think that‘s how it was.)
There are bits of agile that are definitely good, but I think like any business methodology if you just apply it slavishly it’s no better than anything else. (And of course if you’re an X Consultant the last thing you want to hear is “but that’s mostly what we do already”.)
I’m very much for full test coverage, somewhat less for tests-first at the high level, because sometimes the structure of the thing needs to change and the original test plan won’t work any more.
(But I have just written a couple of library functions to convert between Y-M-D and Julian day number… in PostScript. So, yeah.)