4 ms·
(!) This! First, big props for shipping stuff that people use. Second, I've [1] often compared 90% of what we do in software development to being highly train
by denster 6y ago
(!) This!
First, big props for shipping stuff that people use.
Second, I've [1] often compared 90% of what we do in software development to being highly trained baristas. Granted, this buys me little love from engineers & even less from Starbucks.
To the point -- I think it's time we rise up & start to use more powerful tooling.
Tooling that:
1) Lowers the barrier for who can author software (really, web-based interfaces that help us get stuff done, the way we want to accomplish a task)
2) Doesn't introduce more chaos (disparate data spread across 10 SaaS products, death by 1,000 spreadsheets by email or in Google drive, no centralized/secure/managed storage, etc)
3) Emphasizes that a superb user experience is table stakes for such tooling.
Thoughts?
--
[1] founder of https://mintdata.com https://mintdata.com here, so just a tad biased, take the above with a few pounds/kilograms of salt.
[2] oblib -- DM me, we're happy to give you free access if you'd like -- the above wording just warms our collective hearts.
- taurath 6y ago> highly trained baristas And its sort of an insult to training, since there is very little actual formal training. Over 95% of the processes I use in developing software and systems are ones I've learned on the job, not learned while learning to be on the job. An apprentice system would work extremely well with software development.
- denster 6y ago200% agreed. I learned to develop software [1] before the interwebs, where we would just kind-of hack things together in C/Unix. Manuals were our only (& best!) friend. I then went to uni for a CS degree, and they had a very "holy grail" attitude about the whole affair. I agree that: 1) an apprentice system would work better 2) we have got to get more powerful tooling out there, into people's hands -- [1] founder of https://mintdata.com https://mintdata.com here, which makes me biased on the above [2] I'm still reminded of a world where the bridge between creating & using software was much smaller (not to mention, user interfaces were much snappier!) Here's a virtual toast to hoping we can one day come back to that reality.
- lostcolony 6y agoI'd agree with this, but I'll also mention that my undergrad degree was actually phenomenally helpful. One or two classes were legitimately beneficial for what they said on the tin (i.e., taught me useful concepts more quickly than I could have learned them on my own, or taught me concepts I never knew I needed, such as agile methodologies), and the rest presented problems in a space I could comparatively safely 'fail' in, that I had to figure out how to solve on my own, both technical and people based ones. But that said, I also recognize that that may be the exception, and that on the job I might have learned the same things in less time.
- throwaway_pdp09 6y agoI'm going to disagree here, though sort of understand what you and the original poster are saying. In short I've seen the mess that 'unsilled' people make using complex tools. Tools such as databases (my area) are presented as being easy to use by microsoft, who make a lot of effort to make it easy to use. Too easy. Not because I want to keep people out, far from it, but because if they don't know what they are doing they get only so far, then things go bad and they've no idea why. Drag/drop, point/click only goes so far. I guess no complex tool can be (or should be?) used with concomitant levels of training. It's not an argument for code gurus to make themselves a comfortable walled garden to preside over and keep others out, it's an argument that tools should come with training, always. The problem these days is the hirers just want everything (blah blah full stack blah) and don't understand the cost of getting it wrong because it works - up to a point. MSSQL, Spark, Kafka, down to failure to understand how CPUs work. They all get treated as black boxes, and that's fine up to a point. Then things break or don't scale. Out of my sphere I see so many websites that have no basic understanding of usability, or standards, or accessibility, security and by web devs that barely understand HTTP. If it's plain line of business, unimaginative gruntwork that keeps a business alive with spreadsheets etc, then that's what's needed and basic understanding is sufficient. I've done plenty of jobs like that, they keep the economy going, but if you want heftier dev work, I don't think that will suffice. I guess that makes me sound a snob. Not intended that way, just saying complex tools may not be usable to their full capacity without understanding them. I may be wrong too.
- slifin 6y agoI don't know, if a system exposed a EAVT database like Datomic where you don't need to normalise tables and you don't have to index manually and the n query problem isn't an issue then I think a non expert could get a lot further with the right UI then someone given a traditional SQL/NoSQL database It's easy to make things complex and its hard to make things simple but if we can simplify to a data model then we can do declarative programming and make systems more tenable Thinking in declarative data models is hard if you're not used to doing it, I'd recommend looking at the following libraries in Clojure: Garden, Hiccup, HoneySQL or Drupal's form management, or kind of ReactJS if you stretch your idea is what data is, they can all handle complex but focused tasks
- oblib 6y agoThat's a pretty sweet looking tool set you've put together. That looks like something small businesses would love have someone onboard that knows how to use it. I'm not a spreadsheet power user. I've not really done much at all with them, but I'd love to tinker with Mintdata!