With bullshit jobs, could you expand on finding meaningful work? It's something that has eaten me up the last while (non meaningful work and being unsure what direction to head to find it)
I've searched a few reviews of the book but largely seemed to focus on how many jobs are pointless rather than finding non pointless stuff
Any advice on finding a working logical argument? I find myself stuck in unhelpful loops sometimes i.e. Do I enjoy my job? Do I have a sense of purpose in my job?
I realise the answer will be personal and only I can provide it but I'm consistently failing and it's impacting my mood
Looking forward to it! Shout here if you have trouble getting in touch.
Testing can be a satisfying and fun career choice, but in order to grow you need to find a way through the thickets of self-promotion by high-profile consultants and forests of low-quality discussion. There are isolated island communities of folks trying to push the craft forward, but they're doing it without much current or historical context. You need to build your own synthesis. Frankly the field is a mess and it's no wonder testing is held in such low regard.
Improve testability throughout applications by working with their team, setup and maintain test frameworks (hopefully improving them over time), determine what tests should be automated and those that shouldn't, write automated tests, coach team members on writing automated tests and testing in general, add new tools/processes to improve testing, investigate the application in-depth to find risk areas.
I'd be curious if HN think the above includes things that shouldn't be there or is missing a number of items? I'd be curious what the 80/20 for an automation engineer looks like?
I think there's a change occurring recently (last 3-4 years), especially in the larger tech companies with respect to this role. There are still programmers dedicated to writing and maintaining the automation infrastructure but most of the test are expected to be written by feature developers.
Understanding the build system and devops in general is important because if the teams you work with use continuous integration then the test systems interfaces with it.
I work on a team dedicated to making build and automated test reporting better (see my profile) so obviously I have an interest here but I think great reporting is often overlooked and it's crazy because all of the effort involved in automation and writing tests is only valuable if everyone can see the benefits and resolve failures immediately.
I think you're jumping to an awful lot of conclusions there?
The reason I'm targeting automation is that it tends to be done really badly in most companies. At the moment I feel I do it pretty well but always seek to improve. At the moment I don't feel like I'm improving much and want to avoid things staying static for long. Therefore I'm trying to re-evaluate the basics or gain new insight and get back on track
I absolutely hated the robot framework. The DSL was just horrible to use. It had weird, unnecessary syntax quirks and gave you the minimal amount of information if something failed (wouldn't tell you which line number it failed on, for instance).
The tests were also flaky as hell but that was more to do with poor environment management. That, admittedly, was also easier to fix in python.
