There are ways to bypass the standard hiring process. But, they do not work in the short term. If you need to jump ship fast, this will probably not work for you. However, if you have time, it might pay off better.
What do you think?
I got a couple of responses to yesterdays email saying that framework knowledge isn’t that important and you can pick that always up on the go as a reasonably skilled dev. So, if the job required Spring Boot you could still get it without knowing Spring Boot beforehand if you are skilled enough aka a good dev.
A few weeks ago I launched a side-project of mine, a regional job portal for developers. As with any new app I needed to prefill it with data and on an ongoing basis. It takes time until companies post their directly. For that, the app polls a few APIs for getting job posts. Unfortunately, they still use XML. Yep, no JSON.
The dev who created the adapter worked also on the other parts of the system before. As I joined the company, he basically handed the whole system over to me over a period of a few months, I think. We even started brainstorming/prototyping a new web service so the core func can be made available as a web service instead of a lib. The lib approach caused a few troubles as there were some external maintained apps and they hesitated to update the core at all - political games.
Sounds like a simple question, but is it?
Today I was helping out on a second project from the stone age. It’s at least a decade old and still running and maintained. After checking out, I dared to run a mvn clean install and guess what happened?
As much as I love Java, yeah it is still one of my languages of choice after 2 decades, one thing that feels pretty annoying all the time is adhering to the Java Bean convention and thus providing getter and setter and sometimes a few others. The convention itself makes sense and a lot of the libs in the Java world require it. Yet, it never made it into the compiler and automatically provide it. Kotlin does it, why not Java?
There’s a confluence for the project from stone age I am helping out. Its aim is to provide the documentation for the project. Unfortunately, it does not have a clear focus for whom it is written.
Yep, a documentation has an audience - the stakeholders. Depending on the audience, it contains slightly different information, e.g. third-party devs connecting to the system want to know how to do just that and how they can map their business use cases to the systems API; on the other hand, the internal devs are probably not interested in such details as they care for their business use cases. Same goes when the audience is non-dev too.
Sandeep joins the discussion and comes up with a question regarding out-of-date documentation.