Interchangeable implies monoculture and homogeneity
I’m now at the stage of my life where I have accrued some measure of experience and marginal success (insert the appropriate Liam Neeson quote here). I’m also quite expensive, because I’m a middle aged man that’s been on some career trajectory; yet at some level I’m viewed as being interchangeable with some other anonymous developer. This has got me thinking as to whether that’s really the case or whether like most things, it’s that way because that’s the easy way out.
Since the whole work from home thing has started; there have been a couple of changes that I’ve noticed. First of all: I used to be able to use Teams on my personal hardware; but now I can’t because they’re not managed by the company. This has had the sad side effect of forcing me to consistently use my corporate laptop because I can’t use my personal hardware with Teams; sure I can use the web based version of teams, but Edge/Chrome on Windows can’t seem to use my bluetooth headset properly (it works fine with the skype windows app) which I suspect is because the context switch from high def sound to low-def sound so we have the bandwidth to use both speaker + mic is what’s confusing the browser (web skype test call takes ages to funnel sound to the headset).
This post isn’t about the that, it’s about gradle which I have some control over. What I’ve noticed is that intermittently my gradle builds fail with Read timed out issues; this made me think that our external facing artefact repo was having issues, until I realised that it absolutely never happened when I wasn’t on the Mac.
I have questions about your project; you should have done the thinking already.
I have chief in my job title. Does this makes my opinion count for more? Not really, I just have more paperwork to do; more board reports to write; fewer things on my to-do list that I find interesting. Because of my so-called job title, I’m asked to review / rubber stamp projects and approaches because no-one likes to take reponsibility for the decision. This means more meetings and less time actually building things. What’s frustrating about a lot of the meetings is that people aren’t prepared sufficiently. They aren’t prepared to do the hard work up front; they simply want to be able to carry on as they’ve always done. I’m not Bill Gates, and this isn’t one of his infamous technical reviews, but if I can get to the stage where you sound ill-prepared; it’s not going to end well.
Code analysis is good; some code analyzers are closer to my definition of useful
I quite like LGTM since it doesn’t tend to flag up that many false positives when scanning your code. The problem with a lot of the code analysis tools like spotbugs, sonarqube, codacy etc1 is that they often apply rules without understanding the context or the style of the code in question; having false positives as shown2 is frustrating, and invariably ends up with a large number of customised rule configurations for any new static code analysis tool, or in fact ignoring the tool completely and marking it as worse than useless (which isn’t helpful either).
Other code analysis tools are available, like scrutinizr, PMD, etc ↩︎
You can argue this is a style thing; but this is absolutely a false positive. ↩︎
Pictures make people think you care about documentation!
What I’ve often noticed is that javadocs are kind of treated as a second class citizen when it comes a lot of opensource projects; not all projects, there are some with excellent javadocs; but, sadly, more often than not javadocs are an afterthought. Now, I’m as guilty as the next person for not having great javadocs; but you can spruce up your javadocs with some pretty UML diagrams courtesy of plantuml, graphviz and umldoclet…
