3 ms·

At least with Git there are _tons_ of ways to learn more. With Excel there are next to none because of the lack of developer community. There are few useful res

by css 8y ago

At least with Git there are _tons_ of ways to learn more. With Excel there are next to none because of the lack of developer community. There are few useful resources where someone can go to understand how they can best leverage their toolset. Excel is also notoriously opaque when it comes to debugging, so there often are not useful questions to ask Google if you don't already know or understand what you are looking for.

gerdesj 8y ago
Actually there are some bloody good books on the subject. The help files and online from MS help are not too bad. Debugging: "excel debug a spreadsheet" - quite a few decent returns on page one and two. Related searches in Google gives some more hints.
- eponeponepon 8y ago
  A shameful secret: I firmly believe that the moment I became a programmer was when I discovered Debug.Print in VBA in some elderly version of Excel (97, probably) while bodging pretty charts together for someone to print and fax to someone else. I'm willing to bet that I am not alone. Don't be too hard on Excel - some of today's clueless spreadsheet monkeys will be real bona-fide developers in fifteen years.
  - gerdesj 8y ago
    Many zillions of years ago (OK about 23) I was taken on, fresh from the dole, by a factory that made pies (pasties, sausage rolls, pork pies etc (south west UK)) to do the whole IT thing. Anyway, apart from a few other handy skills I learned to bodge a pretty decent spreadsheet, building on experience starting with Super Calc. I converted planning from Lotus 1-2-3 to MS Excel (for shame) and then with my smart Pentium 60 based machine, developed a nearly complete finite capacity planner for the factory - in Excel. The devil is of course in the detail but my labour plan and forecasts beat the planners most of the time - except at Easter and Christmas. Today, I'm really not a developer 8) I grew up and became a sysadmin (oh and a managing director - but that's another story)
- pitay 8y ago
  From memory help for the MS Office products was actually really good. You had sections that showed their object model in a very nice hierarchical manner and you could easily drill down to the individual methods of the objects mentioned. They also had a solid base object library across the Office applications. Things seemed to get more difficult with Office 2007 though, as compared to Office 2003 and earlier. With 2007 and later I believe you were supposed to use Visual Studio to extend it rather than using the inbuilt VBA. Also there was a lot of individual web pages describing how things were done and stackexchange questions answered for Excel and other Office products so it was pretty easy to get decent information to help you. The exception being when searching the internet the only answer to a question was that it was 'impossible to do' when actually it really wasn't, with the effect that most people reading the answer will do it the long and more error prone way. Warning: This is from memory quite a while ago and it was a very minor part of stuff I did at my job then.

by css 8y ago

gerdesj 8y ago

Actually there are some bloody good books on the subject. The help files and online from MS help are not too bad. Debugging: "excel debug a spreadsheet" - quite a few decent returns on page one and two. Related searches in Google gives some more hints.

eponeponepon 8y ago
A shameful secret: I firmly believe that the moment I became a programmer was when I discovered Debug.Print in VBA in some elderly version of Excel (97, probably) while bodging pretty charts together for someone to print and fax to someone else. I'm willing to bet that I am not alone. Don't be too hard on Excel - some of today's clueless spreadsheet monkeys will be real bona-fide developers in fifteen years.
- gerdesj 8y ago
  Many zillions of years ago (OK about 23) I was taken on, fresh from the dole, by a factory that made pies (pasties, sausage rolls, pork pies etc (south west UK)) to do the whole IT thing. Anyway, apart from a few other handy skills I learned to bodge a pretty decent spreadsheet, building on experience starting with Super Calc. I converted planning from Lotus 1-2-3 to MS Excel (for shame) and then with my smart Pentium 60 based machine, developed a nearly complete finite capacity planner for the factory - in Excel. The devil is of course in the detail but my labour plan and forecasts beat the planners most of the time - except at Easter and Christmas. Today, I'm really not a developer 8) I grew up and became a sysadmin (oh and a managing director - but that's another story)
pitay 8y ago
From memory help for the MS Office products was actually really good. You had sections that showed their object model in a very nice hierarchical manner and you could easily drill down to the individual methods of the objects mentioned. They also had a solid base object library across the Office applications. Things seemed to get more difficult with Office 2007 though, as compared to Office 2003 and earlier. With 2007 and later I believe you were supposed to use Visual Studio to extend it rather than using the inbuilt VBA. Also there was a lot of individual web pages describing how things were done and stackexchange questions answered for Excel and other Office products so it was pretty easy to get decent information to help you. The exception being when searching the internet the only answer to a question was that it was 'impossible to do' when actually it really wasn't, with the effect that most people reading the answer will do it the long and more error prone way. Warning: This is from memory quite a while ago and it was a very minor part of stuff I did at my job then.