Discouraged Developer(tbray.org)
tbray.org
Discouraged Developer
https://www.tbray.org/ongoing/When/201x/2014/07/17/Discouraged-Developer
4 comments
I think "Full Stack" developer is a more of a character trait than a badge of knowledge. I.e. it has to do more with being stubborn enough to debug problem after problem like this until the entire thing is working, vs. skills in yet another ephemeral technology.
And that too, you will have to do across all the layers in an application stack.
Is interesting to think in the lack of effort in build simpler/smaller system aka programming languages. Instead, it become bigger, messier and harder. Some more than others.
But look like developers (at large) fight with Java-like bureaucracy instead of replace it.
For example, In https://news.ycombinator.com/item?id=8048014 is discussed how great could be the use of Nimrod, but the lack of ecosystem kill this for a lot of people. The energy on build it is hard. However, the energy of battle against the complexity of a ecosystem like Java is bigger... so weird, not?
But look like developers (at large) fight with Java-like bureaucracy instead of replace it.
For example, In https://news.ycombinator.com/item?id=8048014 is discussed how great could be the use of Nimrod, but the lack of ecosystem kill this for a lot of people. The energy on build it is hard. However, the energy of battle against the complexity of a ecosystem like Java is bigger... so weird, not?
It's not that there's a lack of effort to build simple things ... in some ways it's actually a symptom of the overzealous effort people make to keep simplifying things. Every time we see a tiny bit of complexity some innovative developer says, "I know, I can make a tool / library for that!". The new tool / library solves one piece of complexity but it adds to the overall burden of complexity that we all have to cope with. It's like the whole industry has ADHD, we just can't sit still for longer than 5 minutes.
I think the general rule is that complexity will inflate to about the point where a person with moderately high IQ can't understand it any more. So if you start with a beautiful simple language (say, Python or Java) people will immediately use their free mental "bandwidth" to start adding layers on top of that complexity, and they won't stop until they basically can't understand it themselves any more. Then we will go through another cycle of simplification where someone invents a new language or approach and everyone flocks to it because it is simple and they can understand it and start assembling complexity on top of that ... (Gradle, which Tim refers to, btw, is a perfect example of that ...).
I think the general rule is that complexity will inflate to about the point where a person with moderately high IQ can't understand it any more. So if you start with a beautiful simple language (say, Python or Java) people will immediately use their free mental "bandwidth" to start adding layers on top of that complexity, and they won't stop until they basically can't understand it themselves any more. Then we will go through another cycle of simplification where someone invents a new language or approach and everyone flocks to it because it is simple and they can understand it and start assembling complexity on top of that ... (Gradle, which Tim refers to, btw, is a perfect example of that ...).
> someone invents a new language or approach and everyone flocks to it because it is simple and they can understand it and start assembling complexity on top of that ... (Gradle, which Tim refers to, btw, is a perfect example of that ...)
Unfortunately, Gradle chose Groovy for its programming interface, and Groovy was designed to be complex so its backers could sell conferences, courses, and consultants. Thankfully, it looks like Gradle's going polyglot soon, their Gradle 2 roadmap [1] talks about a configuration-on-demand build model which could expose an API usable by any scripting language, like with vertX.
[1] http://forums.gradle.org/gradle/topics/revolutionary_new_gra...
Unfortunately, Gradle chose Groovy for its programming interface, and Groovy was designed to be complex so its backers could sell conferences, courses, and consultants. Thankfully, it looks like Gradle's going polyglot soon, their Gradle 2 roadmap [1] talks about a configuration-on-demand build model which could expose an API usable by any scripting language, like with vertX.
[1] http://forums.gradle.org/gradle/topics/revolutionary_new_gra...
I've noticed you relentlessly and persistently post comments that are deeply critical of Groovy. To put it bluntly, I pretty much ignore everything you say on this topic because I have surmised that you have some deep issue or axe to grind that is beneath it all. I am curious however what that deeper issue is. Clearly from your depth of knowledge you had a heavy involvement at some point, but at some point something deeply alienated you. I am not casting a judgement here about whether you're justified in that, but I like to keep an open mind. If you are willing to tell me (privately if necessary) I am interested to know what your side of the story actually is.
I don't note which username I'm replying to when I post a comment because it seems many HN commenters use many different usernames, but I can avoid replying to yours if you like. As for my deep issue or axe to grind, nowadays I try to avoid talking about my personal motives because in the past people have used that to deflect attention away from tech issues and timelines and use cases and the stuff that matters, so I'll decline your invitation.
I post comments about and replies to stuff that interests me such as Groovy, including the org.codehaus.groovy implementation. You mentioned your take on Gradle and the simplicity/complexity cycle, and I was giving my opinion on it.
I post comments about and replies to stuff that interests me such as Groovy, including the org.codehaus.groovy implementation. You mentioned your take on Gradle and the simplicity/complexity cycle, and I was giving my opinion on it.
Yes, that is it.
Can be argued that the problem is that everyone keep grinding until is too late to simplify it, ie, the activity of simplify stuff must be done more often.
Also, make things worse than complicated stuff is now a huge legacy and then even if you have a better/simple tool is necessary to mess with them.
Can be argued that the problem is that everyone keep grinding until is too late to simplify it, ie, the activity of simplify stuff must be done more often.
Also, make things worse than complicated stuff is now a huge legacy and then even if you have a better/simple tool is necessary to mess with them.
You know, there's just so much. I've been at it four years and I still feel like a damn newbie.
Gotta know your linux, your scripting, vagrant, docker, salt, git, testing, continuous integration, editor(evil + emacs in my case), algorithms, datastructures, best practices, libraries you are currently using, sql, how servers work, how the web works, memory management, and on and on and on.
On top of that, synthesize all of the above into something usable and maintainable, then maintain it. I'm starting to suspect the day I have a good grasp of the basics is the day I become a master.
Gotta know your linux, your scripting, vagrant, docker, salt, git, testing, continuous integration, editor(evil + emacs in my case), algorithms, datastructures, best practices, libraries you are currently using, sql, how servers work, how the web works, memory management, and on and on and on.
On top of that, synthesize all of the above into something usable and maintainable, then maintain it. I'm starting to suspect the day I have a good grasp of the basics is the day I become a master.
My inclination is towards the idea of learning what you need, and learn enough about it to make/code something valuable.