terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

Flat Daddy: Dec 3, 2014; by Nyc_Tattoo

when you get there push them to rewrite in nodejs

# ? Jul 2, 2015 15:43

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 21:39

jony neuemonic: Nov 13, 2009

bobbilljim posted:

should i work with php y/n

probably not.

# ? Jul 2, 2015 15:57

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Bloody posted:

always be exiting

# ? Jul 2, 2015 15:59

jesus WEP: Oct 17, 2004

who cares what language you get paid to write bad code in, just stack that paper

# ? Jul 2, 2015 16:00

jony neuemonic: Nov 13, 2009

if you're hellbent on using php, at least do yourself a favour and use an ide. there's no compiler to catch anything early and debugging it at runtime is a huge pain.

# ? Jul 2, 2015 16:07

fart simpson: Jul 2, 2005; DEATH TO AMERICA

i wrote a thing in rust and haskell for work today :q:

# ? Jul 2, 2015 16:13

Stringent: Dec 22, 2004; image text goes here

fart simpson posted:

i wrote a thing in rust and haskell for work today

i'd love to hear more about this

# ? Jul 2, 2015 16:28

MononcQc: May 29, 2007

I started my professional work on a lovely old 10 year old PHP code base, but was paired with good engineers and some people from way back when the code base started. It proved to be an incredible experience in terms of knowing what tiny things grow up to be terrible down the road, things of what not to do, and how to organize things better.

I have to think it would have taken a few more years to gain that experience when working in a nicer code base.

# ? Jul 2, 2015 16:29

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

MononcQc posted:

things of what not to do, and how to organize things better.

anything you can put in writing or is it just accumulated experience?

# ? Jul 2, 2015 16:30

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

coffeetable posted:

anything you can put in writing or is it just accumulated experience?

Be very careful

# ? Jul 2, 2015 16:34

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

coffeetable posted:

anything you can put in writing or is it just accumulated experience?

90% of design patterns are "the original way we did this turned out to be unmaintainable poo poo, here's how you should do that sort of thing instead"

# ? Jul 2, 2015 16:52

Stringent: Dec 22, 2004; image text goes here

coffeetable posted:

anything you can put in writing or is it just accumulated experience?

have somebody preternaturally talented at reducing complexity in charge of your codebase

# ? Jul 2, 2015 16:55

MononcQc: May 29, 2007

coffeetable posted:

anything you can put in writing or is it just accumulated experience?

It's hard to say. A lot of it is probably going to be a reaction in a code review where I go "noooo don't do this", but some of it has been materialized in blog posts, talks, and whatever:

plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend
planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this poo poo out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.
write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience tends to get thrown away because of very serious assumptions I had made without realizing it.
it's better to fail early and loudly on a few records than slowly corrupting data over thousands or millions of them. It's easier to replay an action or reimburse a customer than realizing the books were wrong for years.
don't optimize for programming speed, optimize for understanding speed. You end up putting a fuckton more time in trying to understand code than writing it the first time around
you should spend time maintaining code, both yours and the code of others. It's less fun than writing new code, but it's way easier to learn what not to do if you do maintain code bases. Senior devs that can just spend their time making GBS threads new code for others to pick up may not improve their maintainability a lot
technical debt is something I prefer worded in the Quebec slang equivalent of 'pelleter par en avant', or 'shoveling forward' (with reference to shoveling snow in your yard, and just pushing more and more in front of you). The cost is not an aside you eventually have to sit down and repay, but a progressive accumulation that keeps making any progress harder.
Global variables are one kind of thing that can break your programs by spookily changing things at a distance. More insidious are entrenched implicit design decisions. Sometimes, an accidental (or at least non-explicit) technical decision has been made and relied on by other components, and there is no way to find about it in code. Documentation or peer experience is the only way to get these aside from diving in the code system-wide to get a good global view of things (and this is costly, may take months to do)
the easiest way to change a component into a legacy system is to have one person in charge of it with no code reviews. Diluting ownership a bit makes it easier over time for knowledge of it not to die. If people know how the system works, it's not yet legacy and it's a good time to clean it up.
if a system runs forever without crashing, the day it is restarted or needs to be is going to be terrible
in a MVC architecture, an ORM is not a model, it's a middleware to make models easier to write. keep your ORM out of my controller
you can't fix a bug or refactor a system you don't understand. Understanding the problem and the code base is step #1 every time.
if you're in a codebase without tests, write tests before refactoring or patching things so you catch some of the unexpected side-effects you'll have. This does tend to lead to huge hulks of terrible tests because codebases not intended for testing just have that effect. Eventually you can rewrite the code to be testable, and then rewrite the tests again.
blaming a library or a compiler for bugs almost invariably leads to useless energy spent trying to blame someone else. the bug is almost always in my own code.
testing poo poo on a crappy computer shows load issues a lot earlier than on a powerful machine. Testing or developing on underpowered hardware can actually be pretty helpful.
when you think of running a cronjob, ask yourself why couldn't you run it every day, hour, minute, second. Is there a way to just do things live? The fewer cronjobs you have, the easier capacity planning and operations become. There's no fun trying to debug scheduling of cronjobs for long running tasks when they start creating contention issues against each other and bleed through your day
have back ups. Have a playbook telling you how to restore them. Have playbook practices so operational knowledge isn't siloed to one or two people exclusively.
simplicity, brevity, and understandability are not the same thing.
writing tests first is the only way I don't half-rear end tests
I still use a pen and paper to draw diagram and solve my problem by hand before touching code
ask someone to review your stuff; they don't have the same context you do and will find questions or alternative ways better than yours

there's probably more of it, and most of it would probably be easier to trigger during a conversation. Most of my time has also been spent working on server-side software, so it may not apply on any other area of the industry.

MononcQc fucked around with this message at 17:05 on Jul 2, 2015

# ? Jul 2, 2015 17:00

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

MononcQc posted:

It's hard to say. A lot of it is probably going to be a reaction in a code review where I go "noooo don't do this", but some of it has been materialized in blog posts, talks, and whatever:

plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend

planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this poo poo out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.

write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience tends to get thrown away because of very serious assumptions I had made without realizing it.

it's better to fail early and loudly on a few records than slowly corrupting data over thousands or millions of them. It's easier to replay an action or reimburse a customer than realizing the books were wrong for years.

don't optimize for programming speed, optimize for understanding speed. You end up putting a fuckton more time in trying to understand code than writing it the first time around

you should spend time maintaining code, both yours and the code of others. It's less fun than writing new code, but it's way easier to learn what not to do if you do maintain code bases. Senior devs that can just spend their time making GBS threads new code for others to pick up may not improve their maintainability a lot

technical debt is something I prefer worded in the Quebec slang equivalent of 'pelleter par en avant', or 'shoveling forward' (with reference to shoveling snow in your yard, and just pushing more and more in front of you). The cost is not an aside you eventually have to sit down and repay, but a progressive accumulation that keeps making any progress harder.

Global variables are one kind of thing that can break your programs by spookily changing things at a distance. More insidious are entrenched implicit design decisions. Sometimes, an accidental (or at least non-explicit) technical decision has been made and relied on by other components, and there is no way to find about it in code. Documentation or peer experience is the only way to get these aside from diving in the code system-wide to get a good global view of things (and this is costly, may take months to do)

the easiest way to change a component into a legacy system is to have one person in charge of it with no code reviews. Diluting ownership a bit makes it easier over time for knowledge of it not to die. If people know how the system works, it's not yet legacy and it's a good time to clean it up.

if a system runs forever without crashing, the day it is restarted or needs to be is going to be terrible

in a MVC architecture, an ORM is not a model, it's a middleware to make models easier to write. keep your ORM out of my controller

you can't fix a bug or refactor a system you don't understand. Understanding the problem and the code base is step #1 every time.

if you're in a codebase without tests, write tests before refactoring or patching things so you catch some of the unexpected side-effects you'll have. This does tend to lead to huge hulks of terrible tests because codebases not intended for testing just have that effect. Eventually you can rewrite the code to be testable, and then rewrite the tests again.

blaming a library or a compiler for bugs almost invariably leads to useless energy spent trying to blame someone else. the bug is almost always in my own code.

testing poo poo on a crappy computer shows load issues a lot earlier than on a powerful machine. Testing or developing on underpowered hardware can actually be pretty helpful.

when you think of running a cronjob, ask yourself why couldn't you run it every day, hour, minute, second. Is there a way to just do things live? The fewer cronjobs you have, the easier capacity planning and operations become. There's no fun trying to debug scheduling of cronjobs for long running tasks when they start creating contention issues against each other and bleed through your day

have back ups. Have a playbook telling you how to restore them. Have playbook practices so operational knowledge isn't siloed to one or two people exclusively.

simplicity, brevity, and understandability are not the same thing.

writing tests first is the only way I don't half-rear end tests

I still use a pen and paper to draw diagram and solve my problem by hand before touching code

ask someone to review your stuff; they don't have the same context you do and will find questions or alternative ways better than yours

there's probably more of it, and most of it would probably be easier to trigger during a conversation. Most of my time has also been spent working on server-side software, so it may not apply on any other area of the industry.

# ? Jul 2, 2015 17:06

AWWNAW: Dec 30, 2008

Stringent posted:

have somebody preternaturally talented at reducing complexity in charge of your codebase

# ? Jul 2, 2015 17:10

MononcQc: May 29, 2007

The following paraphrased discussion happened in a meeting about providing alternative routers and stacks to customers a few months ago:

coworker: "I want a single loving router to be installed there and nothing else"
product: "Why don't we do X so we can provide customers with options of what to do with the router? Why just one that tries to do more?"
coworker: "Because I can't have zero routers and that's what I'd ideally have."

I still think that this is a great idea. It doesn't mean to go for monolithic apps that do everything in the world, but past a point, we're just creating problems for ourselves by trying to be flexible and super featureful.

Also: predictability is loving great to have. I don't care for the fastest system if I can have an okay one that is reliable on these figures. There's nothing better for operations than well known operational boundaries.

edit also: take a break. When you're tired and you can't see clear anymore, you'll spend 10x the amount of time you'd spent if you take a break and come back later. Knowing when to pause and recuperate can really help a whole drat lot for overall productivity.

Know when you're out of your element, and go read books, papers, blog posts. Gain experience indirectly by people who solved these problems (or similar ones) before you did. It's invariably easier than rediscovering it all by yourself.

MononcQc fucked around with this message at 17:13 on Jul 2, 2015

# ? Jul 2, 2015 17:10

Stringent: Dec 22, 2004; image text goes here

MononcQc posted:

It's hard to say. A lot of it is probably going to be a reaction in a code review where I go "noooo don't do this", but some of it has been materialized in blog posts, talks, and whatever:

plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend

planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this poo poo out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.

write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience tends to get thrown away because of very serious assumptions I had made without realizing it.

it's better to fail early and loudly on a few records than slowly corrupting data over thousands or millions of them. It's easier to replay an action or reimburse a customer than realizing the books were wrong for years.

don't optimize for programming speed, optimize for understanding speed. You end up putting a fuckton more time in trying to understand code than writing it the first time around

you should spend time maintaining code, both yours and the code of others. It's less fun than writing new code, but it's way easier to learn what not to do if you do maintain code bases. Senior devs that can just spend their time making GBS threads new code for others to pick up may not improve their maintainability a lot

technical debt is something I prefer worded in the Quebec slang equivalent of 'pelleter par en avant', or 'shoveling forward' (with reference to shoveling snow in your yard, and just pushing more and more in front of you). The cost is not an aside you eventually have to sit down and repay, but a progressive accumulation that keeps making any progress harder.

Global variables are one kind of thing that can break your programs by spookily changing things at a distance. More insidious are entrenched implicit design decisions. Sometimes, an accidental (or at least non-explicit) technical decision has been made and relied on by other components, and there is no way to find about it in code. Documentation or peer experience is the only way to get these aside from diving in the code system-wide to get a good global view of things (and this is costly, may take months to do)

the easiest way to change a component into a legacy system is to have one person in charge of it with no code reviews. Diluting ownership a bit makes it easier over time for knowledge of it not to die. If people know how the system works, it's not yet legacy and it's a good time to clean it up.

if a system runs forever without crashing, the day it is restarted or needs to be is going to be terrible

in a MVC architecture, an ORM is not a model, it's a middleware to make models easier to write. keep your ORM out of my controller

you can't fix a bug or refactor a system you don't understand. Understanding the problem and the code base is step #1 every time.

if you're in a codebase without tests, write tests before refactoring or patching things so you catch some of the unexpected side-effects you'll have. This does tend to lead to huge hulks of terrible tests because codebases not intended for testing just have that effect. Eventually you can rewrite the code to be testable, and then rewrite the tests again.

blaming a library or a compiler for bugs almost invariably leads to useless energy spent trying to blame someone else. the bug is almost always in my own code.

testing poo poo on a crappy computer shows load issues a lot earlier than on a powerful machine. Testing or developing on underpowered hardware can actually be pretty helpful.

when you think of running a cronjob, ask yourself why couldn't you run it every day, hour, minute, second. Is there a way to just do things live? The fewer cronjobs you have, the easier capacity planning and operations become. There's no fun trying to debug scheduling of cronjobs for long running tasks when they start creating contention issues against each other and bleed through your day

have back ups. Have a playbook telling you how to restore them. Have playbook practices so operational knowledge isn't siloed to one or two people exclusively.

simplicity, brevity, and understandability are not the same thing.

writing tests first is the only way I don't half-rear end tests

I still use a pen and paper to draw diagram and solve my problem by hand before touching code

ask someone to review your stuff; they don't have the same context you do and will find questions or alternative ways better than yours

there's probably more of it, and most of it would probably be easier to trigger during a conversation. Most of my time has also been spent working on server-side software, so it may not apply on any other area of the industry.

I identified with pretty much all of these points, but thinking back about how those mistakes were made, with the organization in place, none of them were avoidable.

# ? Jul 2, 2015 17:12

Notorious b.s.d.: Jan 25, 2003; by Reene

MononcQc posted:

when you think of running a cronjob, ask yourself why couldn't you run it every day, hour, minute, second. Is there a way to just do things live? The fewer cronjobs you have, the easier capacity planning and operations become. There's no fun trying to debug scheduling of cronjobs for long running tasks when they start creating contention issues against each other and bleed through your day

batch processing is hell to start with, and cron is the worst batch processing system ever made. it has none of the features one would desire from batch processing.

this drives open source weenies to move their batch processing into jenkins. this gets you some of the features you would expect from a commercial batch processor (chaining, reporting, triggering) but you're still loving sweating capacity planning and contention and/or aws magic

this drives big data weenies to move their batch processing into yarn and map/reduce. this gets you the capacity planning and pretty good responses to aws issues but you just lost all the batch processing features you had on jenkins or your commercial batch processor, and now you are writing very big checks

mononcqc is right. just say no. friends don't let friends batch process

Notorious b.s.d. fucked around with this message at 17:21 on Jul 2, 2015

# ? Jul 2, 2015 17:19

Valeyard: Mar 30, 2012; Grimey Drawer

Notorious b.s.d. posted:

batch processing is hell to start with, and cron is the worst batch processing system ever made. it has none of the features one would desire from batch processing.

this drives open source weenies to move their batch processing into jenkins. this gets you some of the features you would expect from a commercial batch processor (chaining, reporting, triggering) but you're still loving sweating capacity planning and contention and/or aws magic

this drives big data weenies to move their batch processing into yarn and map/reduce. this gets you the capacity planning and pretty good responses to aws issues but you just lost all the batch processing features you had on jenkins or your commercial batch processor, and now you are writing very big checks

mononcqc is right. just say no. friends don't let friends batch process

Control-M is epic

# ? Jul 2, 2015 17:40

VikingofRock: Aug 24, 2008

Hey what were this thread's recommendations for ML books again? I've got a physics background so bring on the math.

# ? Jul 2, 2015 19:32

leftist heap: Feb 28, 2013; Fun Shoe

I can't remember who posted it originally but the recommendation was for Machine Learning: a Probabilistic Perspective. Oh I found the post anyway:

coffeetable posted:

if you're comfortable with basic linear algebra and vector calculus, Machine Learning: A Probabilistic Perspective.

if you're not comfortable with linear algebra or vector calculus, start with Vector and Geometric Algebra, then Vector and Geometric Calculus, then possibly Linear Algebra Done Right just to get a different perspective, then Machine Learning: A Probabilistic Perspective.

# ? Jul 2, 2015 19:44

distortion park: Apr 25, 2011

VikingofRock posted:

Hey what were this thread's recommendations for ML books again? I've got a physics background so bring on the math.

i think it is Machine learning a probabilistic perspective, which i've started reading and found about right for a physics degree, but all the ones on .edu.cn domains are from the first printing and there's like 20 pages of errata not included in that one

# ? Jul 2, 2015 19:46

Workaday Wizard: Oct 23, 2009; by Pragmatica

MononcQc posted:

...
[*] I still use a pen and paper to draw diagram and solve my problem by hand before touching code
...

this is the most important item in the list IMHO

# ? Jul 2, 2015 19:50

VikingofRock: Aug 24, 2008

thanks guys

# ? Jul 2, 2015 19:57

brap: Aug 23, 2004; Grimey Drawer

just put in notice at my job today.

i learned that we weren't really authorized to be using the version control we were using (TFS) and we weren't authorized to use the migration tool to the version control they want us using (svn) and that we basically were able to continue to work by escaping notice.

too god drat much for me.

# ? Jul 2, 2015 20:05

fart simpson: Jul 2, 2005; DEATH TO AMERICA

Stringent posted:

i'd love to hear more about this

programming isn't actually my job so it's nothing big or substantial. i wrote a haskell program to parse through a few hundred megabytes of iOS app logs per day looking for errors that should manifest as an audible dropout in our speakers, and then i wrote a rust program to analyze audio files recorded from microphones in front of the same speakers also looking for dropouts, and then i wrote another haskell program to take the outputs of those previous two and assign them a score based on how many problems we found.

i sometimes end up writing stuff like this to automate tasks people were doing by hand and i always like to use languages none of the software developers know because then i find it funny when management realized my stuff is actually useful and we should have the software team take over maintenance of whatever i wrote

# ? Jul 2, 2015 20:15

triple sulk: Sep 17, 2014

fleshweasel posted:

just put in notice at my job today.

i start my new job on monday

# ? Jul 2, 2015 20:18

Notorious b.s.d.: Jan 25, 2003; by Reene

triple sulk posted:

i start my new job on monday

god drat, sulk

how many jobs do you go through in an average year

# ? Jul 2, 2015 20:52

Marsol0: Jun 6, 2004; No avatar. I just saved you some load time. You're welcome.

jobs are like toilet paper

# ? Jul 2, 2015 21:33

triple sulk: Sep 17, 2014

Notorious b.s.d. posted:

god drat, sulk

how many jobs do you go through in an average year

the company i'm leaving is based in canada so i was a contractor. i'm joining a company that i hope to actually stay with and has a very good name on paper.

# ? Jul 2, 2015 21:36

suffix: Jul 27, 2013; Wheeee!

bobbilljim posted:

should i work with php y/n

eh. it's the worst plang by a much smaller margin these days
the greater danger lies in who you're going to work with

i'd want to ask some questions like
why are you using php? acceptable reason imo is "we know it sucks but we'd rather pay you lots of money than rewrite a large codebase that works". "it's the only thing we know" is sensible but not a recommendation as a workplace
what's your legacy code like and how are you handling it?
how do you do testing?
what other languages do you use when you have the opportunity?
what experience do the people i'll be working with have?

php has improved a lot as a language, but unless your team knows enough to make use of that and to actively mitigate the terrible parts it's still going to suck as much as its reputation

# ? Jul 2, 2015 22:55

Luigi Thirty: Apr 30, 2006; Emergency confection port.

gently caress! I've become the manager's "uhh I broke this and can't fix it, can you fix it" person

I'm too good at database janitoring and figuring out the intricacies of our lovely product

Luigi Thirty fucked around with this message at 23:00 on Jul 2, 2015

# ? Jul 2, 2015 22:57

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Luigi Thirty posted:

gently caress! I've become the manager's "uhh I broke this and can't fix it, can you fix it" person

I'm too good at database janitoring and figuring out the intricacies of our lovely product

how does it compare to retail?

# ? Jul 2, 2015 23:07

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

i have one thing that i've learned over my medium term as a developer for actual money:

write specs

just write the drat spec. it is a hundred times easier to fix the code when it doesn't even exist yet.

# ? Jul 2, 2015 23:30

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

"but i can just code this up really fa-"

WRITE THE loving SPEC FIRST

# ? Jul 2, 2015 23:30

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

you're going to spend enough time in the nitty gritty of "why doesn't this API call work the way I want" or "whoops i took the address of a temporary" as it is, you don't want to spend that time writing the wrong code

# ? Jul 2, 2015 23:31

Soricidus: Oct 21, 2010; freedom-hating statist shill

that doesn't sound very agole

# ? Jul 2, 2015 23:31

Soricidus: Oct 21, 2010; freedom-hating statist shill

just code

# ? Jul 2, 2015 23:32

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

Soricidus posted:

that doesn't sound very agole

it doesnt have to be a long spec, just write out "in order to do X i will do Y, Z and Q; in order to accomplish Q, B, C and D need to happen" and reason it all out

then you can send it to your coworkers for comments while you start hacking, and they can point out issues long before you even implement the bugs

# ? Jul 2, 2015 23:33

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 21:39

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

gently caress, does anyone know about MAPI integration? I have a c# console app that reads a set of custom properties from an msg file by invoking an outlook session and it works perfectly when run locally but on any other machine fails with an "error property http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/[PROPERTYNAME] is unknown" error.

When I inspect the files with MFCMapi the properties are there and it is exactly the same file locally vs on the server yet it fails for no reason I can see. The properties are read using the PropertAccessor.GetProperty method on the message object and everything I can find says that this should work for custom properties as long as the namespace matches with the one set on the object.

Also gently caress Outlook's "haha here's a generic error code that just means "failure" with no more information" behaviour

# ? Jul 2, 2015 23:36

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »