> A lot of it seems to be driven by a need for developers to keep their CVs shiny This is immaturity, not a real need. The people who make the most money in tech aren't the ones with the most buzzwords on their resumes.
I wonder about that. Right now, I can pick up pretty much whatever tech is thrown at me. But any job demands that I have experience in this field or that field which is pretty frustrating tbh. "You don't have experience in this entire react stack? Bye!" oki... I'll look for backend dev? Oh right. Must be fullstack and must know all the JS frameworks. Maybe devops/sysadmin/whatchamacallit? "Must know this particular N…
People who post job ads where you can browse them usually don't understand the job they are hiring for, hence the checklists and keyword screens. So you need to find a way to get in touch with those on the inside who do know, and can make decisions. Hacker news ads are one way, maybe look at stack overflow, certainly look through your network for internal referrals, perhaps some meet ups.
Also I think one should not use the keyword stuffed resume when going through backchannels. Personally I discount them, and focus on resumes with a record of getting things done in a related field.
Many companies have too many engineers (and some not enough). This is mainly due to #engineers = f1(revenue || vc money) while it should be #engineers = f2(problem). Mostly because our industry has no clue about f2 and so falls back to f1. But this also works with business thinking, e.g. CEO thinking techbudget = 0.1 * revenue With the law of the used budget (all people always use up their budget of fear to not get t…
Many companies have too many engineers (and some not enough). This is mainly due to #engineers = f1(revenue || vc money) while it should be #engineers = f2(problem). Mostly because our industry has no clue about f2 and so falls back to f1. But this also works with business thinking, e.g. CEO thinking techbudget = 0.1 * revenue With the law of the used budget (all people always use up their budget of fear to not get t…
A near optimal one is f2(x) = 5 :)
Most efficient is f2(x)=2 or f1(x)=1 I think, not sure yet :-)
The software field is still very young, and there's lots of things we haven't explored yet. A great example of this exploration is the ongoing evolution of javascript from simple scripts to SPAs and a universal compile target. It seems like a lot of effort is being wasted (because it is), but it's similar to startups in the economy. Most efforts fail, but enough succeed that we end up in a better position overall. Th…
I'm all for learning and experimenting, but is it ethical to do it at the expense of paying customers (including employers) on business critical systems, without their explicit and informed consent?
I honestly don't think it's any worse than it has been before. Back in my youth it was "components". If you can encapsulate functionality, then you should be able to compose it like tinker toys. So let's build these "reusable" components which act like black boxes. We'll nail up the API to the wall, and use some kind of versioning scheme to ensure that it's always backwards compatible. We can even build frameworks th…
Yes, but "components" as a concept actually works . Why do you think we keep seeing attempt after attempt to bring the concept into the browser UI ? Software development with components as building blocks maps well to our mental model of how you build things and is extremely productive. Despite the amount of grief that drag and drop GUI builders receive for being too simple, not being explicit MVC, etc., you won't fi…
Yeah, I'm not really arguing that it doesn't work. There are definitely use cases for it. The main thing is that the simplicity is a facade. Generally it's achieved by limiting scope. But as the scope creeps upwards, the complexity of the machinery starts to overtake the complexity of the problem. The biggest issue is that there is a considerable amount of technical lock-in. The solution is so specific that it becomes impossible to change your mind later in the project. Techniques like refactoring are impossible because you've already baked in the subsystem decomposition early, early in the process. The whole thing becomes a brittle mess. But for certain problems (or putting up a quick MVP that you might throw away later), it can be very useful. And as you said, it can be an excellent way to build projects of limited scope with people who are heavy on domain knowledge, but light on programming expertise.
In regards to the SPAs, what exactly is the alternative? In my mind you have two possibilities: 1. The most ideal is to "pick the right solution for the problem." Meaning, you will analyze the problem and do the right thing, e.g. content mainly? server side rendering. web application? SPA. 2. Do what you know, consistently. In many cases, this means using an SPA basically all of the time, whether or not it's necessar…
> Is there a paradigm/language that allows you to write the same templates for both the server side and SPA view? That's the main motivation behind my web framework Sandro. It is just an experiment, but I do just that! See https://bitbucket.org/aurelito/sandro and https://bitbucket.org/aurelito/sandro-lib It uses rhino and domino to render server side using the DOM API. I am busy with work that pays my bills, but I w…
Server side rendering can be done with any JS framework, though often one must compromise performance by using a more heavyweight implementation like jsdom, or some custom implementation if the framework provides it.
I'd say overengineering and premature optimization are nearly synonyms.
They're both bad, of course, but beyond that I'd say they're nearly antonyms. Premature optimization trades structure for performance, overengineering trades performance for structure. You could argue for equivalence under a broader definition of optimization and engineering, but in the context of software engineering the more specific definitions used above seem to be fairly well established.
Premature optimization trades structure for performance, overengineering trades performance for structure.
This makes them the converse of each other, but not antonyms. At any rate, I'm not sure I agree those terms are exclusive to this relation. There can be fast overengineering and slow PO.
Yes, but "components" as a concept actually works . Why do you think we keep seeing attempt after attempt to bring the concept into the browser UI ? Software development with components as building blocks maps well to our mental model of how you build things and is extremely productive. Despite the amount of grief that drag and drop GUI builders receive for being too simple, not being explicit MVC, etc., you won't fi…
Yeah, I'm not really arguing that it doesn't work. There are definitely use cases for it. The main thing is that the simplicity is a facade. Generally it's achieved by limiting scope. But as the scope creeps upwards, the complexity of the machinery starts to overtake the complexity of the problem. The biggest issue is that there is a considerable amount of technical lock-in. The solution is so specific that it become…
There isn't anything intrinsic to the Visual Studio/WinForms or Delphi/VCL environments that prevents you from refactoring an application into a more structured manner as it grows. They simply don't shoehorn you into an enterprise development model for applications that don't require it (or don't require it initially). Thousands upon thousands of large business applications have been written in both, so obviously they were perfectly manageable for that purpose (2-tier, N-tier, web back-end). The point is to create reliable software that satisfies your business needs. One company that I'm familiar with built a beautiful application server/front-end UI in Delphi that uses SQL Server as the database server and serves 160+ concurrent users every day. The front-end UI was a ~16MB .exe, and the application server was a ~8MB .exe, both with no dependencies other than using Windows Vista or higher as the target OS. It was a very impressive application (I wish I had wrote it), and served the ~$45mil company very well.
I honestly don't think it's any worse than it has been before. Back in my youth it was "components". If you can encapsulate functionality, then you should be able to compose it like tinker toys. So let's build these "reusable" components which act like black boxes. We'll nail up the API to the wall, and use some kind of versioning scheme to ensure that it's always backwards compatible. We can even build frameworks th…
In retrospect the 1990s components craze feels rather modest compared to what's happening now though, even if you allow for stupid ideas like CORBA IDL which hardly anyone ever used. Right now it feels like every single tiny aspect of devops or JavaScript compilation/bundling or UI layouting alone has become more convoluted than the entire 1990s software stack. I realize that we are doing a lot more with software now…