Readit Newsglynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
There’s so much good advice in the article and I think most developers know these intuitively to a certain extent. The problem with it though is that corporate culture tends to ignore these and is very unforgiving in my experience. When you have to deliver everything on time, all the time, you can’t take any of this advice and practically use it. Taking time with learning for example is something you can do only when your manager allows it, your peers (technical and non technical) won’t take any issue with it and the price of taking time isn’t going to be a negative performance review.
That's hard. My only advice when working in a stifling, corporate environment is to find out what your education budget is and then use it for the kind of learning I was referring to in the article. (If you don't have an education budget, that's one more reason to start planning a job move...)
glynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
I've skimmed the article and still have no clue what you guys are talking about. Is test harness another word for end to end testing?
Did you see this helpful link: https://littlegreenviper.com/testing-harness-vs-unit/. According to that usage of "test harness", it's not the same as a unit test. It's a way of driving code manually to explore different usages and to recreate certain kinds of bugs. It is used to complement unit tests.
glynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
> You may be held up by a problem in a dependency such as poor documentation. It is tempting to start filling in the missing docs, but try to resist that temptation. Better to make minimal personal notes for now and, after you’ve made good progress, considering scheduling time to contribute some docs to the dependency.
I agree with most of the article, but this part keeps me thinking. Scheduling to contribute later will almost never work. Either I do it now or never. The task is lost in a list of infinitely many tasks. Also, contributing to a dependency (if I understand this correctly) is always something that helps at least two: yourself - doing something good, helping to improve someone’s work, getting something done - and the person who works on the dependency project. The other gets (positive) feedback and knows someone uses their product/software/library
I try to think in terms of owing the dependency a contribution as a small payment for using it, and this bugs me until I do it. But, sure, better to contribute docs sooner rather than not at all.
(One advantage of deferring is that the contribution may be better quality when I've had more experience of using the dependency.)
glynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
> A new project and it’s going to be your best ever
A good defense against this is borrowing stuff from your prior projects, alongside eventually creating templates for the most common stuff.
For example, in new side projects I start, I can borrow the web server (ingress) configuration from the prior ones, same for CI pipelines and a large part of the previous Dockerfiles, sometimes even entire services with all of the annoying setup and configuration stuff already done.
Plus, this way, you have a more or less working baseline and further iteration is entirely up to you - and if you do want to improve things a bunch, then the next time your template will be even better and you'll be able to backport whatever you think everything should have to your other projects as well.
Going with the simplest solutions along the way helps: Bash scripts for triggering builds, CI configuration just calling those, using Docker or similar containers for the environments and builds, your ingress just being Nginx/Caddy/Apache2/..., using PostgreSQL or SQLite and specialized stuff like Redis/Valkey, RabbitMQ, MinIO and so on instead of reinventing the wheel.
Sometimes it's also useful to write utility scripts and even small tools to help with the projects, I bet developers that have been around for decades and are way better than I am have a lot of that stuff, alongside a healthy helping of dotfiles for existing tools to get in the zone while doing the dev work. Although it can also be helpful to go the YAGNI route and customize things as little as possible, like a stock IDE install, not even bothering with the color themes or keybinds or a plethora of plugins - just install and go.
Fair point. I often copy stuff across from one project to the next. But this point is most relevant when I'm using another language etc. for the first time and I'm tempted to try to retrofit all my previous best practices.
For example, I used to work on a mainframe product that dumped the address space to disk on a crash. Then it was possible to build all sorts of fancy tooling to analyse the dump. When I moved to a different platform, without those kinds of dumps, it was tempting to try to reinvent all this stuff, but it would have been a massive time sink (and would have failed too).
glynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
Rolled my eyes on "For experts only: don't do it yet". Shut-up already. I will do it right now because it will nag me forever and then surface will grow, and every time the new code interacts whith what-could-ve-been-optimized I will spend 5min thinking if I should already optimize it
If there's a definite performance problem and a simple solution, then sure, go ahead. But applying every optimisation that comes to mind can produce a dog's breakfast of unmaintainable code and then when a real performance problem comes along, it can be really hard to fix.
glynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
The Oxide and Friends podcast [1] did a whole episode on this: Coder's Block (25 Oct 2021) [2].
It had some good stuff in it, the best of which (for me) was: when stuck, write debugging infrastructure.
[1] https://oxide-and-friends.transistor.fm
[2] https://oxide-and-friends.transistor.fm/episodes/coders-bloc...
Edit: punctuation
Nice - thanks.
glynnormington commented on Developer's block underlap.org/developers-b... · Posted by u/todsacerdoti
I feel like that's great advice for people working on their own side projects.
But... I'm employed? I mean surely it translates to "go on vacation" but it's pretty useless advice for days where you simply have to work and can't just... not?
I take your point as I'm retired. But I had my previous working life squarely in mind when writing the post.
"Sustainable pace" helps, which in my case came down to 37 hour working weeks, not working at weekends, and taking all my vacation (and some extra when my employer let me buy it). I know this might sound like madness to Americans, but as a Brit employed mostly by American companies, it worked fine for me.
I found that taking plenty of breaks during the working day helped. Coffee breaks with colleagues, a decent lunch break (ideally including exercise), and plenty of tea breaks. So many times I've had a good idea or solved a problem during a break, so they are actually productive.
Then there's finding other useful things to do which aren't as taxing as the thing that's blocking you (e.g. the next large feature). Fixing bugs, writing docs, and doing preparatory investigations about the upcoming work are all productive ways to give yourself a bit of a mental break. (This was hardest when working in teams with continual short sprints or doing XP and pairing, but if I allowed myself to start to burn out, my productivity started to decline - essentially my brain was forcing me to take things a little more slowly in order to recover.)
Deleted Comment