4 ms·

> I disagree. I've met a lot of non-programmers who knew a little programming. They were more dangerous than effective. I'm sure you're well aware of this, but

> I disagree. I've met a lot of non-programmers who knew a little programming. They were more dangerous than effective. I'm sure you're well aware of this, but there's a ton of opportunity for even very simple programming to help in cases where people have never thought of programming as a possible solution. (This is how I contributed roughly $3MM of value to one company as a kid who barely knew how to program). On the other hand, it takes a lot more sophistication (I assume, don't have first-hand experience) to add value to a place that already recognizes the value of programming and automates their work.

etrain 15y ago
Fully agreed here. It's amazing how many people could be replaced (or freed up to do better things) by very simple shell scripts or excel macros. This is where someone who knows a little programming but understands the business process really well can be highly effective. The danger, in my view, is that these first simple solutions tend to have more and more bolted on to them and over the years maintaining them is more time consuming than the job they were designed to replace. This is when you hire a good programmer or two to fix things. The trick is figuring out when to pull the plug on the prototype and make things good. I'm reminded of this quote from Mike Lesk about the early days at Bell Labs: "He wouldn’t issue long speciﬁcations; he’d lash together some combination of shell scripts and awk code that did roughly what was needed, tell the customers to send him some clerks for a few days, and then have the customers come in and look at their clerks using the prototype and tell him whether or not they liked it. If they did, he would say “you can have it industrial strength so-many-months from now at such-and-such cost”."
- mseebach 15y ago
  It's really a tragedy that the same company - Microsoft - is the origin of the only reasonably successful business-focused programming environment (VBA) and the notion that interacting with a computer through any other means than point-and-click - especially typing command and editing text files - is hard and is only for stupid geeks with bad hygiene.
  - loso 15y ago
    Microsoft is not responsible for people hating to type commands in the command line, early computing is. In the past you were forced to type commands to get anything done and a lot of people hated it. The introduction of the GUI made things "easy" for most people.
    - mseebach 15y ago
      No, they didn't invent it, and for the most part, GUIs are leaps and bounds better than CLIs. What I'm opposing is the notion that commands and text files are something to be scared of and shun, when there's nothing so hard in it that most regular office workers couldn't pick up the basics on a three day course. And Microsoft pushed that agenda very hard.
kls 15y ago
One of the greatest companies that I ever worked for trained every employee to use Access and to solution for themselves, we had a system that monitored level of usage of an access solution as well as how much revenue it was responsible for. At a certain threshold the solution was deemed business critical and the access solution was used as a prototype for the developers to implement on a more robust solution. It was like working requirements and the whole thing ran very smoothly, needless to say it fundamentally changed my view of stakeholders solutioning for themselves. I also started to see the issue as a management problem and not a technical one, with the proper processes in place, people are empowered.
- 9diov 15y ago
  This is interesting. Could you elaborate on this monitoring system?
  - kls 15y ago
    Sure so for the load monitoring they had a set of tools that where required to generate a new access solution, what this did was two things it set up logging and it would link the access front end to a Oracle backend, so they where really solutioning their data in a centralized DB as opposed to the Access database, but for the most part the users did not know or care. I don't remember the exact load volume but once the logging hit a specific load volume that was when they app would be sent to development for an enterprise solution. monitoring the load happens via tracking the users that connected to the oracle instance and the application id that they where connecting with, also the amount of time used was tracked. Once the app passed the load tripwire we would look at the functionality of the app, turn each discreet piece of functionality into a service on our ESB and wire the access UI to the services, also views would be created in the DB to isolate the data structure that the users created away from the services being created. from here we delivered 1.0, which is basically the same app but now the all of the functionality is delivered via services and available to the wider enterprise, what would happen after this is that the developers would start to refine the data structure and clean it up, refining out duplicate data constructs and utilizing existing functionality where available. As well, a web UI would be developed an eventually the whole solution would be delivered via web technologies. Now as for the revenue tripwire that was more of a mix of accounting and other variables they measured the amount of people that used the system to the revenue it generated, and based on a formula they would deem it critical, then same process would take place. If a system tracked the revenue that it generated, which most did, we would simply wire their Access solution to the revenue reporting service on the ESB and it would be automated, for systems that did not track their revenue, we would either try to develop a way in solution to track it, or the group would be responsible for reporting it. IF it was a pure cost center, they generally waited for the load tripwire.
BCM43 15y ago
(This is how I contributed roughly $3MM of value to one company as a kid who barely knew how to program) Care to tell this story?
- SatvikBeri 15y ago
  When I joined I spent a lot of time asking people what they did, making mind maps, and finding lots of patterns. I quickly realized that there was a lot of repetition, and that in theory it should be possible to automate, though I had no idea how. So I hit the books, learning everything I could about SAS (the main repeated tasks involved reporting/analytics) and Windows Powershell. Eventually I figured out how to automate it all, and did so. This freed up time for a lot of people, let the company hire less, allowed them to meet government deadlines that would have brought the wrath of god upon them if they failed, cancel a $1.2MM consulting project that would have taken 2 years and accomplished half of what I did, made it massively faster to create new reports, drastically reduced our error rates... So basically, the key was that I really put in the effort to learn the business processes and politics, and just assumed that it would be somehow possible to automate all this stuff without really knowing how.

etrain 15y ago

Fully agreed here. It's amazing how many people could be replaced (or freed up to do better things) by very simple shell scripts or excel macros. This is where someone who knows a little programming but understands the business process really well can be highly effective. The danger, in my view, is that these first simple solutions tend to have more and more bolted on to them and over the years maintaining them is more time consuming than the job they were designed to replace. This is when you hire a good programmer or two to fix things. The trick is figuring out when to pull the plug on the prototype and make things good. I'm reminded of this quote from Mike Lesk about the early days at Bell Labs: "He wouldn’t issue long speciﬁcations; he’d lash together some combination of shell scripts and awk code that did roughly what was needed, tell the customers to send him some clerks for a few days, and then have the customers come in and look at their clerks using the prototype and tell him whether or not they liked it. If they did, he would say “you can have it industrial strength so-many-months from now at such-and-such cost”."

mseebach 15y ago
It's really a tragedy that the same company - Microsoft - is the origin of the only reasonably successful business-focused programming environment (VBA) and the notion that interacting with a computer through any other means than point-and-click - especially typing command and editing text files - is hard and is only for stupid geeks with bad hygiene.
- loso 15y ago
  Microsoft is not responsible for people hating to type commands in the command line, early computing is. In the past you were forced to type commands to get anything done and a lot of people hated it. The introduction of the GUI made things "easy" for most people.
  - mseebach 15y ago
    No, they didn't invent it, and for the most part, GUIs are leaps and bounds better than CLIs. What I'm opposing is the notion that commands and text files are something to be scared of and shun, when there's nothing so hard in it that most regular office workers couldn't pick up the basics on a three day course. And Microsoft pushed that agenda very hard.

kls 15y ago

One of the greatest companies that I ever worked for trained every employee to use Access and to solution for themselves, we had a system that monitored level of usage of an access solution as well as how much revenue it was responsible for. At a certain threshold the solution was deemed business critical and the access solution was used as a prototype for the developers to implement on a more robust solution. It was like working requirements and the whole thing ran very smoothly, needless to say it fundamentally changed my view of stakeholders solutioning for themselves. I also started to see the issue as a management problem and not a technical one, with the proper processes in place, people are empowered.

9diov 15y ago
This is interesting. Could you elaborate on this monitoring system?
- kls 15y ago
  Sure so for the load monitoring they had a set of tools that where required to generate a new access solution, what this did was two things it set up logging and it would link the access front end to a Oracle backend, so they where really solutioning their data in a centralized DB as opposed to the Access database, but for the most part the users did not know or care. I don't remember the exact load volume but once the logging hit a specific load volume that was when they app would be sent to development for an enterprise solution. monitoring the load happens via tracking the users that connected to the oracle instance and the application id that they where connecting with, also the amount of time used was tracked. Once the app passed the load tripwire we would look at the functionality of the app, turn each discreet piece of functionality into a service on our ESB and wire the access UI to the services, also views would be created in the DB to isolate the data structure that the users created away from the services being created. from here we delivered 1.0, which is basically the same app but now the all of the functionality is delivered via services and available to the wider enterprise, what would happen after this is that the developers would start to refine the data structure and clean it up, refining out duplicate data constructs and utilizing existing functionality where available. As well, a web UI would be developed an eventually the whole solution would be delivered via web technologies. Now as for the revenue tripwire that was more of a mix of accounting and other variables they measured the amount of people that used the system to the revenue it generated, and based on a formula they would deem it critical, then same process would take place. If a system tracked the revenue that it generated, which most did, we would simply wire their Access solution to the revenue reporting service on the ESB and it would be automated, for systems that did not track their revenue, we would either try to develop a way in solution to track it, or the group would be responsible for reporting it. IF it was a pure cost center, they generally waited for the load tripwire.

BCM43 15y ago

(This is how I contributed roughly $3MM of value to one company as a kid who barely knew how to program) Care to tell this story?

SatvikBeri 15y ago
When I joined I spent a lot of time asking people what they did, making mind maps, and finding lots of patterns. I quickly realized that there was a lot of repetition, and that in theory it should be possible to automate, though I had no idea how. So I hit the books, learning everything I could about SAS (the main repeated tasks involved reporting/analytics) and Windows Powershell. Eventually I figured out how to automate it all, and did so. This freed up time for a lot of people, let the company hire less, allowed them to meet government deadlines that would have brought the wrath of god upon them if they failed, cancel a $1.2MM consulting project that would have taken 2 years and accomplished half of what I did, made it massively faster to create new reports, drastically reduced our error rates... So basically, the key was that I really put in the effort to learn the business processes and politics, and just assumed that it would be somehow possible to automate all this stuff without really knowing how.