I'd do everything different today. Being a nerd, I had absolutely terrible social skills and did everything wrong. I couldn't sell a $20 bill for $10. I've been trying for decades to do better with that.
But the best lesson is to associate with someone who can sell.
Hi,
How did you manage to get them to pay you hourly to create a project plan?
What did you propose? I also need to do this for my venture but never clicks. Please share some advice.
Thank you.
I had done work at Ford and when a project came up there with IBM involved, Ford recommended me to them. Since it was my first contract with IBM, they didn't know anything about me and hired a project manager as a liason. I had already submitted an overall bid for the project, and since it would take more than 6 months, they wanted to do it with milestones so that I actually got some money along the way and they could see that I was capable of doing the work. And, I think they were actually looking out for me, because they knew that someone up the corporate ladder could change their mind and the whole project might get scrapped, they could get someone else to do it, etc.
A detailed project plan is something that both sides have to agree on. The project manager gave me guidance on IBM's expectations but it was up to me to define the "Statement of Work" and I defined the milestones so that there was one every month or two. It was their idea to do this part on an hourly basis. For one thing, the group that was putting my contract together didn't have it ready, so the only way I could work was hourly. A project plan was their requirement, not mine.
Doing a project plan for a fixed cost is doable too. The bottom line is, don't work for free unless you want to. If they want a project plan for a big project but won't pay for your time to put it together, that would be a huge red flag for me and I'd probably pass. If you are the one that requires the project plan, that's a little different and I could see where a customer might balk on paying for that.
An obvious example in the U.S. is that even if you have a contract saying you have to work for someone for no pay, forever, with no possibility of getting out the contract, it would be unenforceable because we, as a nation, have decided that slavery should not be legal.
It turns out, many of these un-contractable issues involve the employer/employee relationship... another example: even if you sign a contract saying your employer doesn't have to pay you overtime, that provision would be thrown out if you challenged it, and would probably get the employer in trouble with various agencies, including the IRS.
I am a lawyer, but I don't have experience in this field, and this is not legal advice (you have to hire me for that), but this issue seems like one that a court (depending on the state, no doubt) would find that it doesn't matter what the contract says, an employer can't own everything an employee does.
To emphasize: this is NOT legal advice, don't rely on it, and you really should seek counsel if you are encountering this issue in real life.
The fact that the employer/employee relationship is so carefully controlled (specifically to limit the power the employer wields over the employee outside employment) is what makes me suspect that at least some jurisdictions would decline to enforce an employment contract provision that gave the employer ownership over all IP the employee produces, even if the IP is produced off-hours, without use of the employer's equipment, and not having any relationship to the employer's business.
Again, I don't actually know for sure - I'm not an expert in this area of law. But I think there is enough evidence in the rest of (U.S.) employment law jurisprudence to indicate that it's not open-and-shut in favor of the employer.
At issue is he says that what he created is within the realm/market of his employer. That would be akin to an Intel engineer saying "I designed another microchip for computers but I promise I was doing this for me and not for Intel so its mine." You cant do some work on specific sector A for your employer and then do some other work in specific sector A on your own and now expect the employer to ask, justifiably, "who decided the dividing line here?"
My apologies, I was responding to the question about why a court would find an employment contract provision unenforceable - we don't know what the OP's employment contract states (or if he even has one), so I was treating this whole line of inquiry as separate from the OP's situation. Didn't mean to confuse the issues.
Some states (don't know in USA, speaking from EU) have laws against "unfair clauses" which make those automatically null even if you accept it. Usally the point is that for each clause in a contract which put an obligation on the employee, the employer must "give something back" to repay for that obligation in equal terms.
In this case in my state the employer should at least have paid for all the time out-of-work in which op worked on his IP, and with a rate established by op
Contracts state a lot of things that don't necessarily hold up. It's just words on paper. Sometimes they're even tenable in one area, then used in another state which disallows some claim or another.
Employment contracts in particular are subject to a lot of restrictions and protections regardless of what the employer makes people sign, because labor laws.
Depends on where you are. In the EU, parts of contracts that sre against the law, which includes labor without payment, are invalid and you are free to sign it.
In this case, giving up IP you made in your free time requires a new contract, because the law also requires a purchasing contract to have clear parameters
I only shared it on my personal social media (not a big reach) and created a profile for it on Indie hackers. Unfortunately, I can't see how the first customer found me.
I have no context regarding the history of the benchmarks game. With that in mind, I have a question:
What about you create a technical specification (including both technical depth and common-sense breadth) for what kind of benchmark you'll accept, throw the whole thing on GitHub, and then refuse 99% of pull requests? :) (ie, only accept really really good quality benchmark implementations)
Eventually, enough developers unimpressed that Language X is not adequately represented would step up to the plate and maintain good-quality benchmark code. (This could get pretty interesting with rapidly-evolving languages like Rust.)
Obviously this is all very ideal and I can see so many ways such an endeavor could go horribly wrong, sure. I can also very easily see you having floated such an idea then discarded it for reasons I haven't even thought of.
What about I work to publish crowd-sourced programs and measurement scripts: so that anyone can make their own comparisons, on their own hardware, against whatever other language implementations they want to write programs for :-)
The only thing I wonder about is allowing any given set of hardware to be compared with another set of hardware with anything approaching accuracy.
What would be awesome is if someone could figure out whether they'd need Raspberry Pi Zero to run some algorithm or if they could get away with just using a BBC Micro:Bit, by looking at a benchmark run submitted to the site from an i9-7940X.
Sadly I suspect the amount of realtime introspection needed (memory speed, practical cache coherency (per level), bus saturation, instructions used per cycle) would make this difficult - particularly because, even if a given benchmark was going to go fishing for performance counter info (and I just learned that even the Gen1's ARM 1176-based PMU provides a few, including one that counts instructions), benchmarking memory I/O is a bit harder; PCI DMA MMIO debug cards only map a small range of memory, like 256k or so, and I don't know if such cards can back the region with actual RAM. I suspect the access latency would be so different than from normal RAM that even if this did exist it'd never be used. Sigh.
And then differences in compiler optimization approach would have to be taken into account, and thorough understanding of assembly language for all target architecture(s) would be needed to have the time of day to page through the diff analysis...
Hmm, I think "simple" got left behind a few thousand miles ago. It's kinda (morbidly?) fascinating how different that different architectures are on the ground, hah.
- I now realize (after having actually had a proper look) that while the Micro:Bit does use "JavaScript" and "Python", they're different, microcontroller-specific implementations, and I should have used a different example there, like an Intel NUC or perhaps an ODROID board or similar.
I know you're publicly directly messaging, but as an outsider to the discussion, I don't see any actual mention in your posts why D isn't included. Just that it "used to be."
There are many of benchmark projects that include D and don't appear to be struggling under any kind of massive burden. For example:
What are your actual reasons for not keeping D... "scala... and Clojure and ..."? The results in the previous link show D as a massive competitor (sometimes 1st place beating C and C++) on both memory and speed. Wouldn't the purpose of benchmarks be... to highlight useful, highly-scoring languages? Isn't that one of the primary reasons people read benchmarks?
(The D implementations are also often smaller in lines of code, as per this benchmark project:
I know how good D is and I have a lot of confidence in it. There are a lot of great people using it that are getting their jobs done faster & better and are thereby making more money. That's what matters to me.
Everybody likes to make more money :-)
Back when I was a brand new engineer at Boeing, I was talking to my lead engineer about the beauty of aerospace engineering. He smiled and said I didn't get it. Boeing wasn't making airplanes, they were building money making machines for airline companies. That the airplane turned out to be a beauty was just a happy side effect!
D isn't about my personal aggrandizement. It's about how effective it is for users at solving their problems and making money for them.
Has there been any recent discussion on this? I suspect earlier reasons might have included D not being packaged for Debian?
It can be though to shake "early license impressions" - D (dmd specifically) is one example, Ada (FSF GNAT vs AdaCore's GNAT Pro and Ada-gnat - GPL w/o runtime exception) is another.
[ed: if others are interested in "make your own measurements and host it yourself", relevant page with link to code etc appear to be:
Not since I asked him to stop dropping by the D forum to remind us that he wouldn't include D in the shootout.
I've personally lost all interest in it.
(The benchmarks are also small and too easily gamed by the author of the benchmark code, and the compiler developer. I encourage people to run timing tests on their own code, as that is what matters to them.)
My experience has been that I get better ideas of benchmarks by profiling my real application code, porting the hotspots to the new language or framework within a mostly bare skeleton and testing it. It’s not perfect, but gives me a better idea as to whether moving will actually help!
> I encourage people to run timing tests on their own code, as that is what matters to them.
This is the heart of the matter: benchmarking toy and unrelated bits of code amount to the same thing.
I think what people really need is a straightforward, accessible understanding of where a software implementation is inefficient. Design inefficiency can sometimes be "hacked over" (read "paved over") a bit like evening out technical debt; implementation inefficiencies, perhaps not so much. Making a complex database query faster by fiddling with (very) obscure SQL options because a given vendor's query planner is broken in a rare edge-case is one example that comes to mind.
I think it's especially sad when a software implementation becomes renowned for its inefficiency. It kinda takes the heat off in what I would argue is a very unfair way, like it legitimizes slowness like speed isn't a worthy pursuit... and then we wonder why our computers are slow. (Yeah, I'm thinking about Python here... and to a small extent many interpreted languages.)
In the context of D (and now DMC++ :D), so specifically compilers, it would be interesting to know what areas of the language don't generate especially fast code, or what bits might produce code that uses a little memory than it could, etc. Because that's what people really want to know before they take the time to write/port; and if they know about all the instances of "don't do XYZ in this very specific way" ahead of time, maybe they can write the best possible code on the first try! (Design and implementation are intertwined in practice.)
I suspect the list of such "avoid"s may not be long. It might make for a particularly efficient kind of developer user manual.
I don't really see a big problem with a little bit of gaming on the benchmark-code side; with a few implementations to compare, it might even give some hints for idiomatic efficient code.
Gaming from the compiler/runtime side would be uglier - but I guess it is somewhat mitigated by real languages running the "general release" version.
No harm in "fastest way to list first 1000 prime numbers" being "print static list of first 1000 prime numbers".
Hand there's some value in having a standard benchmark harness that works easily across languages - as a helpful tool with "running your own benchmarks". Assuming the harness is any good, that is.
> I don't really see a big problem with a little bit of gaming on the benchmark-code side
I just got tired of the vitriol leveled at me with no basis. Things like I must have "sabotaged" other compilers. Probably the absolute worst one was when the journalist decided that Datalight Optimum C ran the benchmarks so fast, it must be a compiler bug and removed the benchmark results from his compiler roundup, calling DC a buggy compiler.
The reality was Datalight C was the first C compiler on DOS to do data flow analysis, and it deleted dead code. (Benchmarks of that era did nothing useful, and dfa detected that.) No cheating at all. A couple years later, everyone did dfa.
I did run my own prime number crunching benchmark for fun and D blew Rust away but lagged behind Go. I used mutable Vec and HashSet in Rust, associative arrays and arrays in D, maps and arrays in Go to store the sieves.
You see, that's the point - even if you do something as simple, there are many ways to do it (and different compiler versions, especially in the case of D), different optimizations at the code and compiler level and all that - it's practically impossible to have a reliable, comprehensive benchmark.
The Rust HashMap and HashSet implementations are generic over hasher: you can pick a faster one if you don't have to worry about getting ddos'd. Last I checked, the go-to fast hasher was fnv: https://doc.servo.org/fnv/
How often do I need to explain that this siphash claim of DDOS protection is utter nonsense. siphash can easily be brute forced like every insecure hash function (<256 bits), and proper DDOS protection can only be provided by a proper collision strategy. Even DJB himself does so.
Is there any way to use it directly in the source w/o having to create a Crate.toml and src dirs? Is there a getting started document? Dub recently included such a feature.
https://doc.rust-lang.org/cargo/ has installation, getting started, a reference, all of that. It needs some work, but for the basics of doing this, it's got it all.
Not sure why you're getting down voted was about to post something along the same lines (though admittedly linking to a couple of threads, not just the search). But I don't think everyone on hn would be aware of the d forums (nor that it's a rather magnificent piece of "groupware" with usenet and irc support on top of (or should I say beneath) a quick Web interface.
From my perspective, the relevant "couple of threads" would be the old discussions which showed various people in the D community actually had the measurement scripts working with D programs: and yet that work becomes abandoned, so there's nothing like —
(a) In the short run, a good job generally gives much better financial returns than a startup. From the overall vibe of your post, I would say don't startup unless you have a compelling drive to startup.
(b) Stay sharp. Don't depend on "bigco" to manage your career/skills for you.
(c) Spend wisely, Save wisely. There's no silver bullet there. Of course all the savings might not be enough for certain cases, but that holds true for both bigco and small biz. Don't become a slave of your lifestyle while the going is good for you whether it is a small-biz or a bigco job.
I have tried D, loved the language but I feel the ecosystem and environment issues need to be addressed asap. Here are a few inputs
(1) setting up env different operating systems eg GNU/linux variants. Compilers ldc, etc are not really easy to setup on all systems.
(2) Memory usage during compile can get out of control resulting in mid-build crashes if sufficient memory is not available.
(3) Setting up of a simple http server should be made simple. (ideally the way Go allows to convert any regular Go program to a http server)
