41–50 of 90 posts
One of the premises of this article - that "competing standards" exist primarily because of political reasons or shallow decision making - demonstrates a fundamental misunderstanding of software engineering. Sure, some engineers (especially junior ones) enjoy reinventing the wheel more than using something that already exists to solve users' problems. We all like to trick ourselves into thinking we're unique snowflak…
Earlier quoted context omitted.
By "more visual" do you mean diagrams?
Pretty much. One ideal might be for a flow chart to come alive and actually be the structure of your application itself, rather than just a reference or an aid. I suppose that while visual programming excels at conveying topology and structure, it can be weak at a low level due to the tedium involved. Traditional code is arguably better suited for low-level grunt work, at least for most people. A hybrid solution migh…
Earlier quoted context omitted.
Programming is not designed to solve those things - they're not problems created by programming, but by: * Incompetent management * Lack of communication * Rush to market, rather than integrity of solution * No solid requirements The unfortunate irony here is that the startup mentality promotes the above problems because it's generally not trying to solve a problem, but make money.
Wow, I am not in a startup but a well-established company, yet your list of issues is exactly the issues I am currently facing! Sad really.
Many reports show how time-to-market is more and more important, and 'agile' is the only way.
Even companies well-versed in proper engineering practices move towards the modern 'best practices' and acquire all of the best problems at the same time.
I see this kind of article posted regularly, and it has been for at least the past decade (if not longer.) Worse, it's often accompanied with 'but profession X is so much better and they are all certified and do things properly unlike us awful cowboys!'. In the worst case you get the whole 'in the future everyone will program and programmers will become totally redundant'. I have a feeling the developers writing thes…
Yeah, not going to happen because not everyone can think in the level of detail required to program.
Some people just think programming is like waving a magic wand, but when you keep asking them "so, what should it do if this happens? What about if that happens?" they slowly start to understand...
We may be programming in our different teams, companies, organisations and countries, but the stuff we make makes an impact and affects the world around us.
This impact is an input into future similar projects and, given time, the technologies that results from wherever will be better for it. Please note that this idea does not mean that any group now is going to make these technologies, but what we do now will influence the future.
The same pattern has been observed in the industrial revolution - many tinkerers, manufacturers and inventors were all sort of learning from each other, all improving. This happened over decades. The main difference with programming is the time dimension. We've only really been doing it at a cultural level for the last twenty years - we're only just getting started in discussing and sharing what we are doing.
It's worth mentioning that Chris Granger wrote an excellent blog post[0] that's similar to this one, but far more succinct. While I don't use Light Table, I'm still a huge fan regardless. > What would programming be to you in an ideal world? More visual, especially when observing execution. When you're debugging anything non-synchronous—be it events, messaging, distributed systems—it usually sucks, even in the rare c…
By "more visual" do you mean diagrams?
Also many people don't use what is available to them. Modern IDEs support single-stepping and painless runtime introspection, and many have supported it for 20 years.
Still people resort to trying to trace out in their head what happens runtime.
This article more than anything underscores my feeling that there are too many people in programming who should not be doing it in the first place. It's a skilled profession, but it's increasingly dominated by people who despise the craft aspect of it. This results in both, suckage and bloat on the one end, and unrealistic expectations on the other. > Hiring developers is an extremely difficult task. Learning to prog…
And this was in the CSE stream which was for the less able children.
Here's the thing: everything sucks. Every industry, profession, even hobby is full of seemingly arbitrary limitations, poor tooling, quirky hacks you have to work around, little bits of required know-how that seem ancillary to the central goals. Ask your friends in other engineering disciplines, politics and public policy of all kinds, finance, medicine, and energy. Everything sucks because the world is complicated a…
the problem is, that doesn't pay for a roof and a meal.
so I spend my day fighting users that requires twenty seven pop-ups not to delete their own data accidentally, browsers that have each their own idea of css3, enterprise services that are a landmine of old documentation, bugs, workarounds, workarounds for bugged workarounds and bugs on top of these.
as my mentor once said, if work were fun they wouldn't have to pay you to do it.
No one is going to listen to this - but what the hell: The solution is totally obvious. The code we write has a form defined by it's input->output mapping over all possible inputs. Write a function and you immediately define this input output mapping. All you have to do at this point is search through all previously written functions to find the one that most resembles the one you are trying to write. Trying to write…
This magical repository you seek is called "stackoverflow" :-D
Taking the creativity out of an inherently creative process. Imagine you're a painter and then comes some moron (who is probably not a painter) yelling at you: - Why are you holding the brush that way? Also, I don't know that brand. - You should make thinner strokes, and always start coloring the surroundings so you don't go over by mistake. - Do not bother with the first brushes until you have a clear pencil sketch.…
In pure software engineering there is much less creativity needed than most people want to admit. While the UI/UX people gather requirements and work with the client to work out how the app should look and behave, sure, they can use their imagination. But once the requirements are set then in many cases a software engineer can sit down and build the software. There is no creativity needed to decide whether to use a v…
Coders often like their craft, they like creating things, even if the final product is not important to them on a personal level.