What is the best source on these topics?
I’m not being cheeky here. I’m genuinely interested, because I see these terms thrown around a lot without reference.
With regards to design patterns I would recommend the Gang of Four book on the subject. It's old (to the point where it makes me feel young) but still relevant as most of the patterns you'll see in the wild will be described there or be slight variations.
For security I've heard people describe the OWASP Top Ten as the software equivalent of the Ten Commandments. It's been around for almost two decades and is also still very much relevant today, perhaps even more so going by the comment you replied to.
I don't know Rect (besides implementing the todo list they have in their frontpage), but I can learn in a few weeks to become proficient on it. Don't hire "React developers", hire "good developers".
On the backend at the Principal level, I’ve see the opposite thankfully. Most companies don’t seem to care about the specifics—the current buzzword with is that they care that I can design “web scale” systems (regardless of whether the company actually has web scale problems—but that’s a different problem).
Indeed. So then they'll go ahead and design "web scale" solutions to non-existent problems. I quote web scale since in the majority of the cases I've seen, the solutions don't actually seem particularly capable of handling massive scale but since they don't need to, it never gets tested.
Worked with one company with this ginormous logging and analytics pipeline which consumed most of the AWS budget, but the actual data flowing through it amounted to a handful of million entries per year. Yes year. At that scale, the wise solution is grep and awk on a $5 VM.
Solve the problems you actually have and the ones you can project to having in six months. Don't solve the problems you wish you'll have in ten years.
In general that is not necessarily bad, it can be a good thing.
> they keep learning framework and library without caring about software principle, architectural or design patterns or security best practice
My guess here is that it is a way to get into more interviews. Many job openings today lists a ton of libraries and frameworks that you should have experience with, thus the market reacts(!) accordingly.
I don't really know whose fault it is, but I can tell you from experience that if you present yourself as having good -even excellent- experience and knowledge of the principles, the practices, and the patterns, and having similar experience with $similarFrameworkA and $similarFrameworkB, but not with $thisParticularFramework, then "you're not quite what we're looking for". And the opposite is common too. If you do have a couple of years experience with $thisParticularFramework you're good to go. It doesn't matter whether you don't know how to do anything else outside of that.
This is something people don't often want to admit, or sometimes even discuss. I'd guess it may be related in some way to another rarely admitted fact about the industry: There is a lot of wasted effort and resources. Particularly in certain types of projects and companies, the overall productivity is extremely low.
If I compare that to my own experience learning web dev in the early 2000s on my own. Make a html file with some css and ftp it up to a server. First version done. Add some JS, some PHP, then a database. Eventually move from vanilla code to different frameworks and languages, move from a Linux box to some cloud services, slowly start working with more complex systems and different paradigms. The whole process was very iterative and I feel I have gotten a lot of transferable knowledge on the way.
Of course this is perfectly possible to do these days as well, but it is not what I see happening or being widely encouraged in communities or fostered within companies. It seems more about run this and that generator script, click this button to spin up the managed services to run it on. See, it is so easy, so no problem. Creating hundreds of dependencies and layers of abstraction with practically no idea what they do. I had people wanting to learn programming from zero asking me to help with issues with their docker setup before having written a nested for loop.
I'm definitely not against those "modern" tools, they can be an awesome productivity boost if used well in the right context, but I can't help but often feel reminded of the good old Jurassic Park quote when it comes to tech stack decision making: "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should"
I'd rather search by that and then see what their tech stack looks like and filter down to the ones matching my interests and the tools I like using. Heck, there may be a company that I'm really interested in what they're doing but I may not have a lot of experience with their particular technology set. I could reach out to them and express my interest in what they're doing and see if it might make sense for me to join them. Focusing on technology feels like putting the cart before the horse.
DocUI, the back-end SDK that uses Flutter for the front-end, is actually multi-language on the back-end. But I also have a back-end web-framework built on top of Jester that handles user management. Another example is an ORM that generates Nim data access files (which is Postgres only at the moment, but other DBs could be added).
Pretty neat tool, but the region search needs work.
There's a jobs channel there where folks post jobs on these topics there. If you've got these kinds of software internals jobs you're welcome to join and share. If you're looking for these kinds of jobs you're welcome to join and browse.
Unlike OP's site this isn't tied to particular technology/languages/frameworms but tied to particular interesting topics.
[0] discord.multiprocess.io
the job postings are augmented with the dev-stacks (from servers, databases, languages, infra, thirdparties), the job headlines de-b#ll-ified using ML, and the users can apply fast via github / linked or direct via the jobposting on the companies website, every job posting has some salery range. it carved out it's niche in the austrian dev community.
I changed the search to "Common Lisp" and got a few hits. But they were all just places with "Common" in the name, like Revere Hotel Boston Common.
I know there are companies in the area that use Common Lisp, Google/ITA being the primary but not only one. Lisp jobs are rare, but not that rare.
Sorry, but this looks like it's a "maybe someday, but not today" project.
Techmap: Find companies using technologies you love - https://news.ycombinator.com/item?id=28897492 - Oct 2021 (47 comments)
We use Go! (On one service (that's really a proof of concept (our main stack is ASP.NET)))
My younger and naive self used to over value the tech stack of a company, nowadays I don't care, there's way more important issues than the specific tech stack chosen like people, organization and processes.
A strong engineering team pushes for meaningful and well organized requirements collection and encoding, documentation of the business domain, values (meaningful) testing and is strongly oriented towards providing the best developer experience possible.
Languages and libraries do play a part in developer experience and satisfaction, but they are generally way less important.
In this market, employers are saying anything to get folks in the door. They're scrambling for workers, and a lot of times it's because their codebase is shit and folks are leaving in droves, so they dangle carrots to get folks to support their decaying crap.
This seems a little wrong as a region.
I enjoy technology, but it's hard for me to just focus on tech without a purpose for using it. All of the projects I'm proud of aren't because of the tools I used. Instead, I'm proud that I delivered something useful.
Yet, I still completely agree with your statements about "MBA puff". I've been on projects where they extol how valuable a project is going to be and it doesn't stand up to a minute of scrutiny. Other projects would be valuable, but never get into the hands of real users.
On the projects I'm proud of, I was directly working with someone who actually would benefit from the project. There wasn't a question of whether it was worth it. The users weren't puffing up the project to be more than it was. They have a job to do and I'm helping them do it better. Interestingly, this also meant that they didn't care how I approached the problem.
The real sweet spot for projects is where working on interesting tech goes hand-in-hand with delivering something useful.
When I was younger my family was really big into riding ATVs. At first it was cool, but then I started to realize we were just going to drive in the same circles at the same parks forever and it lost all meaning to me. ATVs are cool, I still think they are, but without a reason to ride one I can’t imagine spending a weekend in a tent driving around in circles. At the same time I know plenty of people who live for that, so I recognize that we’re all looking for our own things.
For me, Python always provides the shortest path to solving problems programmatically. It is the best thing you can use to prove a concept before you build something. Python sits appropriately in the middle of pseudo code and something performant. I get to solve unique problems rapidly. That fits my philosophy. If you are comfortable in using something why not get paid to do that. I am open to learning new things particularly Typescript but I am just comfortable in a Python environment more than a JavaScript or any other environment.
The catch with all that is that I am more fitted for contract roles as opposed to full time jobs. For the employer hiring based on tech introduces too much rigidity. They want contractors and experts for that.
Every language has its own ecosystem, its own frameworks, its own culture its own set of "best practices". Good luck learning them all.
You're an expert in knowing how to use a hammer. I think it's the wrong focus. Instead we should be focusing on whether you're a framer, a carpenter, a roofer, etc. It's your expertise in solving particular kinds of problems that makes you valuable, not in knowing how to use a particular tool.
As an aside, some people have noted this is not true for IT contractors - as they are oftentimes brought in explicitly for their expertise in a tool. I would argue that's a reason why a lot of people don't want to be a contractor forever.
Same for me. I can learn whatever tech stack you're using (if need be). I want to know about your business, your product, your future.
I like the idea.
I don't want to go back to a company which is not using kubernetes for example. I'm also interested in deepening my expertise in it.
Most craftsmen and artists I know are very particular about their tools and much prefer using their own tools that they've lovingly maintained and gotten to know all the quirks of rather than some random tool someone hands them.
Some are coin-operated. Some are language/stack-driven. Some want fast-growing; some want slow-and-steady. Others like small companies. Others like large stable companies.
But I know many people who call themselves "PHP devs" or "React engineers" or "Wordpress gurus". This service is perfect for them.
If you only need a view lib: uhtml, lit-html
There are a ton of jobs that are tool-heavy, and the "solving problems" only applies to a small percentage of the team.
Some problems should not exist at all and only exists because of the tooling chosen.
Example: A friend of mine works at a company that is running their business on some clown-ish cloud infrastructure, and their SREs have to basically re-invent the wheel to work around the limitations of the cloud vendor the management has chosen (for example: no virtual machine autoscaling, in a cloud environment). Somebody at that company is certainly doing "creative work" and "solving problems" with code, but not those SREs.
The "Wordpress Guru" is far more akin to the oil-change technician than to the professional mechanic. He likely does not understand HTTP, let alone TCP/IP, he might google CORS when he has a problem, likely copies code from Stack Overflow without understanding it, and has heard of Big O notation but has never had to apply it to his work. Honestly, I'm probably closer to that extreme than I would like to admit, but I do strive to understand ever line of code I'd be git-blamed for, and think that I understand two levels below the technologies that I do use on a day-to-day basis.
Are we really discussing this?
Yea, if you think hard enough, you can have communications sent by horse, instead of by electronic mail.
Yes, the entire software industry is akin to crack dealers.
Of daily infrastructure people already have, because someone dared turn it into software?
> You only need a few of them.
I guess we can keep email, but we should strip all the software layer from waste management plants, or the archiving systems of national libraries and museums, or the operating systems that support the browsers we're typing this from, or the avionics from passenger planes, or whatever you decide is the right number of software applications.
You hit right on the nail, so I don't generally disagree with you. This is how business works, there is no number! Consumerism works the same kind of way.
[Shifted-goal] Also I don't want to stop or reduce it either, I just want more quality of software, not some VC-pipedream-hype driven software.