Guard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes. Static constraints like types can also be also good, where types are good. I applaud anyone who advocates to focus on the unhappy path over the happy path. On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen…
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
Can't Driven Development
21–30 of 54 posts
Re: Can't Driven Development
#22Earlier quoted context omitted.
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
What problem do you have with companies requesting developers know more than one language? If they want a master in multiple then they are fools. But a web developer for example will need proficiency in a few.
Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces, and they push everything to microservices, so they can parse their errors from DevOps services. Which means they don't request only to know multiple languages, but also DevOps services.
I have written about all these in a previous article of mine https://rm4n0s.github.io/posts/5-it-will-take-your-job
Re: Can't Driven Development
#23Earlier quoted context omitted.
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.
Vectorization, more cache levels, branch prediction, multiple cores and processors, gpu, virtual machines, (operating systems, but they didn't change much, I only let the placeholder for the layer), containers, but all that in the cloud, distributed databases, frameworks written in a language that need to be compiled to a language that is actually implemented by a web browser in the client (we are far better on compatibility between browsers, but much libraries or practices keep stuck in the past).
I haven't touched shift in practices that make it far worse.
That make it more unreasonable.
Re: Can't Driven Development
#24Earlier quoted context omitted.
Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.
Yeah because back then the tech stack was: php apache mysql linux it was so small we could put it into an acronym. Meanwhile in 2024 you could barely begin to even describe any individual layer of the stack with so few words. You'd be out of breath before even beginning to finish describing React. (btw it's silicon, not silicone).
Re: Can't Driven Development
#25Guard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes. Static constraints like types can also be also good, where types are good. I applaud anyone who advocates to focus on the unhappy path over the happy path. On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen…
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
Also in a similar regard your article mentions other things like microservices being the root of all evil so to speak and you need to know multiple services.
When in fact microservices are meant to do the opposite. You are supposed to be able to focus on just your service and what it needs to do and make it do it well. Instead of having to wade through a huge monolithic and probably very interwoven code base. We can of course talk about whether microservices achieved that goal.
They are not fundamentally different from having worked in large enterprises 25 years ago where you would've encountered many many different services making up your application landscape. It was probably using SOA and the services were deployed to a bunch of application servers like an IBM WebSphere and those services might be talking to other services incidentally deployed on some JBoss app servers and they'd talk via message passing via a queue (JMS comes to mind but other ways existed).
Re: Can't Driven Development
#26Earlier quoted context omitted.
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
Yes they did. My dad worked in IBM 360 assembler. And in COBOL. And in Natural (yes that's actually a programming language - https://documentation.softwareag.com/natural/nat426mf/pg/pg-... ) And JCL. And I am probably forgetting some. And they had learn their "Hibernate" and JPA etc too (CICS comes to mind). Also in a similar regard your article mentions other things like microservices being the root of all evil so t…
today fullstack developers have to pivot between 2-3 languages on the same day
All the SOA back then was JAVA, they had just different types of HTTP servers to run JAVA
Re: Can't Driven Development
#27Earlier quoted context omitted.
Yes they did. My dad worked in IBM 360 assembler. And in COBOL. And in Natural (yes that's actually a programming language - https://documentation.softwareag.com/natural/nat426mf/pg/pg-... ) And JCL. And I am probably forgetting some. And they had learn their "Hibernate" and JPA etc too (CICS comes to mind). Also in a similar regard your article mentions other things like microservices being the root of all evil so t…
Did your Dad worked on IBM 360 assembler, COBOL, Natural and JCL on the same day? today fullstack developers have to pivot between 2-3 languages on the same day All the SOA back then was JAVA, they had just different types of HTTP servers to run JAVA
I constantly write software in Typescript, Java and Kotlin. Some days it's all of them other days it's only a subset. I don't see an issue with that at all. If you don't have a standard set of languages I would agree with you but a stack of one frontend and one backend language should not be a problem for anyone that calls themselves full stack.
The SOA point was not about languages any longer. It was about having multiple services that make up an overall feature and app landscape. Also you seem to have missed the part where I said that I was not in fact HTTP calls is manyif not most cases ;)
Re: Can't Driven Development
#28Re: Can't Driven Development
#29Earlier quoted context omitted.
Did your Dad worked on IBM 360 assembler, COBOL, Natural and JCL on the same day? today fullstack developers have to pivot between 2-3 languages on the same day All the SOA back then was JAVA, they had just different types of HTTP servers to run JAVA
All four probably not. He might have worked on some feature in COBOL that then required a new/change to a channel program that would have been written in assembler and at the end of the day write some JCL to get a job to start. Yes. I constantly write software in Typescript, Java and Kotlin. Some days it's all of them other days it's only a subset. I don't see an issue with that at all. If you don't have a standard s…
Re: Can't Driven Development
#30Earlier quoted context omitted.
All four probably not. He might have worked on some feature in COBOL that then required a new/change to a channel program that would have been written in assembler and at the end of the day write some JCL to get a job to start. Yes. I constantly write software in Typescript, Java and Kotlin. Some days it's all of them other days it's only a subset. I don't see an issue with that at all. If you don't have a standard s…
And how is your social life? Do you have a girlfriend?
I fail to see how one has anything to do with the other.
Knowing and applying both Java and Typescript is not an issue at all. What is a pain is CSS and why I tell everyone I'm a BE dev. But I happily build vertical slices of functionality where I have full control over FE and BE code and can adjust as I see fit instead of having to create or follow a rigid interface definition and where the BE isn't user testable when it gets written. What is a pain is the libraries on the FE but that's not an issue with knowing multiple programming languages but with the web dev FE ecosystem in general. A non full stack FE developer would have the same pain.
While we did learn a programming language at university to code our exercises in, we didn't learn that language specifically as "this is the language we teach and this is what you will use in your job until you retire". On the contrary we were told and taught about programming concepts, data structures and algorithms and it was expected that you can program in any language. The (mandatory) operating systems course for example would just assume that you learned enough C by yourself to do the programming exercises. We had to write a working memory compactification algorithm for Minix. In the scripting language course (non mandatory) you had to choose any scripting language you wanted and implement a project in it. In the mandatory hardware course we were expected to pick up enough VHDL to implement whatever we learned in the course.