Review of "How to Make Your Career Suck Less: A Guide to a Less Painful IT Experience" by Igor Ljubuncic
One of us at Tux Machines recently read the new book "How to Make Your Career Suck Less: A Guide to a Less Painful IT Experience" - a relatively long book from Igor Ljubuncic, whom some people know and refer to as "Dedoimedo". Below is a concise, edited version of the review. It has been added and then edited for clarity, not just concision.
"I'm not in any of the apparent target groups," noted the reviewer. "The useful advice given in the book is better early on in a career, before it starts sucking. Prevention is more effective than attempts at corrective effort. Maybe there is a sweet spot for this material where someone is early in their career and looking ahead enough to see the problems but could benefit from this advice to circumvents many of them."
The reviewer suggested examining "5 types of bullshit jobs" and said "citations [were] needed for the many assertions made". For instance, on "how to manage managers", the "finance advice in how to talk to senior managers seems sound, but some of the larger places are so &*&*%^ hierarchical that only certain titles are even allowed to talk to management and even then only the lowest level."
Regarding the format of the book (electric copy), "no page numbers in the Calibre E-Reader," the reviewer noticed, "at least by default".
"The presentation advice seems to match up with experience," the reviewer said. "Don't even attempt to use a Windows laptop at a tech conference, poorly timed updates or not. Have several backup copies of the presentation available, at least one USB stick and at least one HTTPS site. (File formats for presentation graphics used to be an issue, even with the same brand of software, so I used to mainly scroll through a web page made for the presentation and fall back to the presentation graphics with missing or faulty Internet access.)"
"Don't count on having useful bandwidth or even working Internet," the reviewer said. "Have a backup plan for that if you are going to demo something remote. Live demos are to be avoided when possible."
"I've never run into a projector where the resolution or colors match anything useful," the reviewer said. "Prepare by resizing your display resolution. Whether to use a mirroring or second display approach is debatable. Mirroring means that you generally see what is on behind you without having to turn, but every mouse movement or other mistake with be 100% visible. I'd say not just mute notifications but temporarily quit all programs not involved in the presentation or even use a second account made just for the presentation event. Repeating questions aloud is *very* important for conference recordings. It'll likely make the different between whether someone watches through to the end of the Q&A or closes the tab and moves on."
"Time allocation advice is spot on," the reviewer said about the book. "Creation of a story arc is quite useful but could be better foreshadowed in the presentation section."
"Blog posting advice seems good," said the reviewer, "though Roy's experience could be tapped in the review."
Ljubuncic blogs a lot too. He wrote about blogging many times, especially in Dedoimedo, his personal site.
"I agree strongly on the no SEO approach," the reviewer said, "aside from an information retrieval perspective which makes it essential to have correct use of headings, page description and keywords, valid formatting, well-written body, incoming and outgoing hyperlinks, and so forth. Those are the correct elements of any document, SEO or not. Aside from making a correct document, SEO is not just a waste of time but actually counter productive as the algorithms change. Humans are the target audience, not algorithms. It does not matter how high up it ranks in the search results if the structure and content discourage a person from reading it. There is great value if the information in a document reaches just that one person who needed it, when they needed it."
"Advice on white papers seems sound," the reviewer noted, "though I must admit to having only a little experience in that area."
"I do think patents are evil and do have data to support that position and how they (especially software patents) actually harm innovation," the reviewer said. "However, just don't use the false phrase 'Intellectual Property' and we're good. PJ [of Groklaw] used to ask, if it is property, then where are the property taxes?"
"However, since the book tries to address patents I will throw in an anecdote from someone I knew: realize that some of the larger companies will do everything in their power to keep employee names off of patents. They will go as far as firing some of their best employees and blackballing them such that the can never work in the industry ever again. Even bringing the topic up can put you on the company's shitlist. Is first-to-file universal? I had the impression that it is not."
"The "do not search online" is important advice there," the reviewer said. "When CD-ROM was still a thing, companies (wisely) refused to use online services with the same data because they could not control who could monitor the search logs. Then there is also the matter of triple damages for 'willful' infringement. Microsoft GitHub is to be avoided. Codeberg and GitLab are two better options."
The reviewer said that "Open-Source" with a hyphen is "usually used by Microsoft scammers," so "I would recommend keeping the normal un-hyphenated "open source" spelling."
"The licensing table is rather unclear," the reviewer remarked. "Sorry I cannot rework it to show an improved arrangement, but it took a long while to puzzle over. Maybe a decision tree or flow chart would be better..."
"There is a high ROI for readable code," the reviewer opined. "It is said that code is read many more times than it is written or edited. Perhaps more emphasis on style a la OpenBSD's style(9) guide would help. There are a lot of good arguments against CLAs and NDAs which could be included in the book."
"Skills vs tools is a good distinction to keep," argued the reviewer. "It should be pointed out that there has been a giant movement towards the decommodification of Linux through proprietary interfaces and APIs."
"IMHO certifications are largely a waste of time except for "box tickers" as defined in David Graeber's book "Bullshit Jobs" from 2018," said the reviewer.
"Mentors can help focus learning away from non-productive endeavors and towards useful paths."
"The difference between tools and skills can be repeated multiple times throughout the chapter for emphasis."
"Scientific method should be highlighted prominently and the main way for problem solving," the reviewer said. "The chapter covers it, but the intro could be more focused. I'm not sure the data analysis segment adds anything as it is at the moment. qualitative vs quantitative is worth exploring..."
"For development," the reviewer said, "I've been favorable to Rapid Prototyping which I guess might fit under 'Agile'. There are few situations where waterfall can be of use, in practice. In grad school, whenever someone spoke a buzzword in my direction, I stopped them and asked for a clarification of what was meant. Eventually people stopped throwing buzzwords around until after I graduated."
"Wasting time is hard to avoid if people are around you wasting time," said the reviewer, "they will drag you into their mess. E-mail is not so unproductive in and of itself, but the joke of an interface which people use (web mail) makes it impossible for it to be useful. Time management skills are essential to being efficient."
This review does not come with a score, but it seems like the person behind Dedoimedo expresses or articulates experiences others have learned firsthand. █