4 ms·

The line I found most insightful: >>"Software is much more intertwined with the institution commissioning it and the people using it ..." Given that, I'm surp

by qxf2 14y ago

The line I found most insightful: >>"Software is much more intertwined with the institution commissioning it and the people using it ..." Given that, I'm surprised at the emphasis on 'reading' as the primary source of gaining domain knowledge. There are just 2-3 mentions of speaking/collaborating with the domain experts that are driving you to build the software itself. If you are lucky enough to work with acknowledged domain experts, spend time talking to them. Pick their brain. Two techniques I use: a) forward interesting articles to them with a question or an analogous concept in my domain b) resist the urge to show them a 'better' way. E.g.: In the HealthCare domain, I learnt people don't really want quicker or lesser clicks. They would prefer a set, stable workflow. If you cater to senior-citizens, keyboard shortcuts are less important than instructions in large font. I still suck at engaging domain experts. So, I'd love to learn more techniques to hold an interesting conversation with domain experts. Ideas?

jacques_chester 14y ago
I can read a book faster than I can speak or hear words. In addition, books can usually be found, on almost any topic, which are intended to bring a novice up to a basic level of conversancy. Reading one (or two) such books will make discussions with the experts much more productive. Plus: it's fun to learn about new things.
- qxf2 14y ago
  Oh, no argument on the fact that reading is extremely useful. I read too. In expressing the balance between reading and collaborating, I felt that your article emphasized too much on reading - but I fully recognize that you do collaborate. >>"I can read a book faster than I can speak or hear words." I disagree that this is an argument in favor of reading. Reading is easier but I think its not always as high in quality as collaborating. >> "Reading one (or two) such books will make discussions with the experts much more productive." Totally agree. I try my best to read as much with the end goal being picking the brains of my colleagues.
  - jacques_chester 14y ago
    > I felt that your article emphasized too much on reading You've mistaken me for Jacques Mattheij.
    - qxf2 14y ago
      Ooops. Mea culpa. Sorry.
      - jacques_chester 14y ago
        No worries. It's kinda flattering. Plus "Jacques" is an uncommon name in the anglosphere, apart from South Africa.
majc2 14y ago
I'm surprised about the emphasis too. In terms of ideas, I used to work in a large corporate on the technology side - now work for a software company, so YMMV with these: One of the first projects I worked on involved re-writing an entire admin system, both the technology and the underlying processes. One technique that worked well for the team, was to work-shadow; we would each spend time watching how a couple of people worked; compared notes and would go back and ask questions if we didn't understand it. Work shadowing doesn't have to be project related either; I visited nearly every department in our division of the over the years (1 every couple of months). I even managed to swing going out with the sales guys and visit clients; the clients were happy to spend an hour talking about their business and problems. Anyway, my experience with large corporates if that if you ask - people are generally happy to help you out - but I think many people just censure themselves from asking in the first place. One other technique that I think works quite well is to get the strong end users seconded to beef up the QA team. Again, this doesn't work in all environments. But in the context of developing an internal system, it worked really well. For an external facing system, we did get a sales guy seconded onto the team too - which again really helped build up the knowledge of the whole team. A variant on reading is podcasts and forums - I've used both of those to get to grips with whats going on in an industry. For the software company, most of the above doesn't work, we're adapating Steve Blank's mantra of "get out of the building" and just trying to talk to as many people (especially customers) as we can. If they agree to talk to you, they're generally going to be helpful.

by qxf2 14y ago

jacques_chester 14y ago

I can read a book faster than I can speak or hear words. In addition, books can usually be found, on almost any topic, which are intended to bring a novice up to a basic level of conversancy. Reading one (or two) such books will make discussions with the experts much more productive. Plus: it's fun to learn about new things.

qxf2 14y ago
Oh, no argument on the fact that reading is extremely useful. I read too. In expressing the balance between reading and collaborating, I felt that your article emphasized too much on reading - but I fully recognize that you do collaborate. >>"I can read a book faster than I can speak or hear words." I disagree that this is an argument in favor of reading. Reading is easier but I think its not always as high in quality as collaborating. >> "Reading one (or two) such books will make discussions with the experts much more productive." Totally agree. I try my best to read as much with the end goal being picking the brains of my colleagues.
- jacques_chester 14y ago
  > I felt that your article emphasized too much on reading You've mistaken me for Jacques Mattheij.
  - qxf2 14y ago
    Ooops. Mea culpa. Sorry.
    - jacques_chester 14y ago
      No worries. It's kinda flattering. Plus "Jacques" is an uncommon name in the anglosphere, apart from South Africa.

majc2 14y ago

I'm surprised about the emphasis too. In terms of ideas, I used to work in a large corporate on the technology side - now work for a software company, so YMMV with these: One of the first projects I worked on involved re-writing an entire admin system, both the technology and the underlying processes. One technique that worked well for the team, was to work-shadow; we would each spend time watching how a couple of people worked; compared notes and would go back and ask questions if we didn't understand it. Work shadowing doesn't have to be project related either; I visited nearly every department in our division of the over the years (1 every couple of months). I even managed to swing going out with the sales guys and visit clients; the clients were happy to spend an hour talking about their business and problems. Anyway, my experience with large corporates if that if you ask - people are generally happy to help you out - but I think many people just censure themselves from asking in the first place. One other technique that I think works quite well is to get the strong end users seconded to beef up the QA team. Again, this doesn't work in all environments. But in the context of developing an internal system, it worked really well. For an external facing system, we did get a sales guy seconded onto the team too - which again really helped build up the knowledge of the whole team. A variant on reading is podcasts and forums - I've used both of those to get to grips with whats going on in an industry. For the software company, most of the above doesn't work, we're adapating Steve Blank's mantra of "get out of the building" and just trying to talk to as many people (especially customers) as we can. If they agree to talk to you, they're generally going to be helpful.