Be careful! Side projects can get you into legal trouble, if you’re a salaried employee of a tech company. Most companies (at least in the US) will have you sign an “Intellectual Property Agreement” or “Proprietary Rights Agreement” when you accept the position. This usually signs over to them the rights to any inventions you come up with, no matter when or where, during the term of your employment, as long as those inventions are related to the company’s field of business.
It doesn’t matter if you did the work on your own computer.
It doesn’t matter if you did the work on evenings / weekends.
It doesn’t matter if it’s open source.
It doesn’t matter if you think your project isn’t related to your company’s business. It matters what your employer thinks, and in the worst case what a court thinks.
People can and have gotten in trouble this way. I got hit by it once, not with legal trouble fortunately, but losing a verbally-promised payment for my app. (And looking at it the opposite way, some companies have been hurt by an employee devoting most of their energies to a side project, and then quitting to turn the side project into a startup, or taking it to a competitor.)
The workaround is to talk with your employer before you start the project and get them to make an exemption for it; I discuss this in more detail in the blog post I linked above. (But of course I am not providing actual legal advice…)
Thanks for this wonderful piece of advice. You’re absolutely right - employment contracts should be read very carefully to avoid legal trouble. I gave up on some of my earlier projects partly for this reason.
I found that the more I dig into complex, obscure and low-level topics, the easier it gets to tackle difficult topics. For example, after having explored CPython’s codebase extensively, I feel much more at ease in exploring codebases of equal or greater complexity.
I don’t know. I’ve actually never seen an open source project (with more than 2-3 regular committers and sizable userbase > 10) that has exhibited the atrocities of closed-source commercial code that one guy wrote years ago and then vanished. It’s usually like digging out the oldest snapshot of $language from 15 years ago and first of all spending a few hours trying to get it to build, just that it actually has an INSTALL file, so you can poke at it while running it. So yeah, that is one side of “complexity and obscurity”, but that’s my experience from most past employers and customers.
I agree with you that proprietary source code is sometimes (often?) harder to understand than open source. IMO, the lack of documentation/comments, the lack of proper organization and overengineering contribute significantly to the problem.
Perhaps my example could have been a little bit better to illustrate my point. For example, I’ve been working on a compiler/interpreter and a static type checker in the past couple of years. I started from nothing, without any knowledge about those things. At first, it was scary and I found concepts are bit overwhelming. But the more I dug into it, the easier it was to understand. Incidentally, I found that the “fear” aspect has almost completely vanished whenever I dive into complex and obscure topics. This is what I meant.
I got your point, but given a modicum of competence I think a well-documented “hard topic” codebase like a compiler is still a lot easier to navigate and understand than a shitshow of boring enterprise code :)
As a programmer, I’m not naturally business-oriented. So when I need to substantially deviate from coding for a long time, I feel that something is missing. For example, when I was on a roll of speaking with several potential customers a day, it required careful preparation, reviewing of notes and follow-ups.
As a programmer, speaking with customers is one of my favorite things. At one point in my career I was the go to guy for dealing with difficult customer issues. Anything from fixing highly complex issues with high value customers, to answering questions about the product. I was essentially the “last resort” of our support team, despite officially holding the title of software engineer. Many of our high profile customers had my personal cell phone number.
I don’t think I’ve enjoyed any part of my career nearly as much as that, before or since. I found the work so engaging that I never needed to take notes. And I’m by no means someone with a fantastic memory who never needs notes. All the customers and their problems were always on my mind. I just loved the role.
Perhaps my situation is different from what @mbenbernard is talking about. My work involved a fair bit of debugging, which I always enjoy when programming. But my role was as much business-to-business “politics” as it was debugging and support, and I wrote hardly any code myself.
Regardless, I don’t think it’s fair to generalize programmers as business-dumb. And I certainly don’t think I’m some bizarre exception. A dear friend of mine is endlessly fascinated with business and incredibly passionate about his role in management, despite starting as—and continuing to be—an extremely talented programmer.
I agree with the vast majority of what you’ve said. At my previous job, I was also pretty good at solving complex and difficult bugs. Beyond the actual debugging, this involved communicating quite a bit with customers, either via email or by phone. I even visited a couple of customers on-site, which was a lot of fun! I don’t have any problem with that - this is part of a software engineer’s job. Just like you, I didn’t need to take a lot of notes in this context, except maybe for follow-ups with customer support agents and my manager/boss.
Now, put that into the context of a startup, especially at the beginning when you still don’t have any customers and you’re trying to figure everything out. This is pretty much what Lean Startup is about - developing a new product in a world of uncertainty. You don’t know what you need to build, and you don’t know who your customer is. You have a rough idea of what problem(s) a particular category of people may have, but you still need to speak with actual people to validate your hypotheses. So you contact maybe 100 people, among which only about 30% reply to you. You ask them if they’re available for a call, and about 50% mysteriously vanish (they have their own reasons). You ultimately set up maybe 10-20 phone calls of 20-30 mins each to discuss. In this context, it’s useful to take notes, because memorizing everything, and all subtleties, is next to impossible. After those calls, you follow up with people and thank them for their time.
In my mind, these are purely business-oriented tasks, which I happen to enjoy doing. Otherwise, I wouldn’t have done them. However, my first love is programming. I love designing and creating new things. I’m fundamentally a problem solver. So if you give me a choice between business-oriented tasks and programming, then I’ll choose the latter anytime. If it weren’t the case, then I would be in the wrong field.
In my post, I admit that my wording sounded like a generalization, but I was speaking mainly from my own perspective. Besides, I happen to know a few programmers, and the vast majority prefer writing code than doing anything else. They may not be naturally business-oriented, but they’re certainly not “business-dumb” (whatever that means). It’s just a matter of personal traits and preferences.
OP, have you taken a look at pytype? we are solving a similar problem, of inferring types without annotations, and would love to hear from you if you’re interested in contributing, or even just to compare notes on our various approaches.
there’s also a mailing list for people working on various python type checkers that you might be interested in.
Thanks for your feedback and the links, Martin. This is much appreciated.
I definitely know pytype - I admire your work a lot!
For the moment, my project is experimental and closed source. I still don’t know whether it will be open source (under which license?), or whether it will stay closed source and shipped as part of a commercial product. My tool isn’t so much for type checking - although it can do that - but instead it’s made to infer various things that current type checkers aren’t able to infer. It will be part of a documentation tool that I’ve been working on in parallel.
I sincerely appreciate your offer of sharing notes, but since I possibly intend to take a commercial route with my tool, I don’t feel comfortable with sharing how it works at the moment.
Anyway, many thanks for your offer. I’ll keep you posted when I release something.
Be careful! Side projects can get you into legal trouble, if you’re a salaried employee of a tech company. Most companies (at least in the US) will have you sign an “Intellectual Property Agreement” or “Proprietary Rights Agreement” when you accept the position. This usually signs over to them the rights to any inventions you come up with, no matter when or where, during the term of your employment, as long as those inventions are related to the company’s field of business.
People can and have gotten in trouble this way. I got hit by it once, not with legal trouble fortunately, but losing a verbally-promised payment for my app. (And looking at it the opposite way, some companies have been hurt by an employee devoting most of their energies to a side project, and then quitting to turn the side project into a startup, or taking it to a competitor.)
The workaround is to talk with your employer before you start the project and get them to make an exemption for it; I discuss this in more detail in the blog post I linked above. (But of course I am not providing actual legal advice…)
Fortunately, in most western jurisdictions outside the US, such oppressive employment contract provisions (if attempted) would be unenforceable.
Thanks for this wonderful piece of advice. You’re absolutely right - employment contracts should be read very carefully to avoid legal trouble. I gave up on some of my earlier projects partly for this reason.
I don’t know. I’ve actually never seen an open source project (with more than 2-3 regular committers and sizable userbase > 10) that has exhibited the atrocities of closed-source commercial code that one guy wrote years ago and then vanished. It’s usually like digging out the oldest snapshot of $language from 15 years ago and first of all spending a few hours trying to get it to build, just that it actually has an INSTALL file, so you can poke at it while running it. So yeah, that is one side of “complexity and obscurity”, but that’s my experience from most past employers and customers.
I agree with you that proprietary source code is sometimes (often?) harder to understand than open source. IMO, the lack of documentation/comments, the lack of proper organization and overengineering contribute significantly to the problem.
Perhaps my example could have been a little bit better to illustrate my point. For example, I’ve been working on a compiler/interpreter and a static type checker in the past couple of years. I started from nothing, without any knowledge about those things. At first, it was scary and I found concepts are bit overwhelming. But the more I dug into it, the easier it was to understand. Incidentally, I found that the “fear” aspect has almost completely vanished whenever I dive into complex and obscure topics. This is what I meant.
I got your point, but given a modicum of competence I think a well-documented “hard topic” codebase like a compiler is still a lot easier to navigate and understand than a shitshow of boring enterprise code :)
As a programmer, speaking with customers is one of my favorite things. At one point in my career I was the go to guy for dealing with difficult customer issues. Anything from fixing highly complex issues with high value customers, to answering questions about the product. I was essentially the “last resort” of our support team, despite officially holding the title of software engineer. Many of our high profile customers had my personal cell phone number.
I don’t think I’ve enjoyed any part of my career nearly as much as that, before or since. I found the work so engaging that I never needed to take notes. And I’m by no means someone with a fantastic memory who never needs notes. All the customers and their problems were always on my mind. I just loved the role.
Perhaps my situation is different from what @mbenbernard is talking about. My work involved a fair bit of debugging, which I always enjoy when programming. But my role was as much business-to-business “politics” as it was debugging and support, and I wrote hardly any code myself.
Regardless, I don’t think it’s fair to generalize programmers as business-dumb. And I certainly don’t think I’m some bizarre exception. A dear friend of mine is endlessly fascinated with business and incredibly passionate about his role in management, despite starting as—and continuing to be—an extremely talented programmer.
and it perpetuates a stereotype that has the risk of becoming aspirational. Not interacting with customers is not a badge of honor.
I agree with you. Have a look at my comment above - I’ve never said that programmers are business-dumb.
I agree with the vast majority of what you’ve said. At my previous job, I was also pretty good at solving complex and difficult bugs. Beyond the actual debugging, this involved communicating quite a bit with customers, either via email or by phone. I even visited a couple of customers on-site, which was a lot of fun! I don’t have any problem with that - this is part of a software engineer’s job. Just like you, I didn’t need to take a lot of notes in this context, except maybe for follow-ups with customer support agents and my manager/boss.
Now, put that into the context of a startup, especially at the beginning when you still don’t have any customers and you’re trying to figure everything out. This is pretty much what Lean Startup is about - developing a new product in a world of uncertainty. You don’t know what you need to build, and you don’t know who your customer is. You have a rough idea of what problem(s) a particular category of people may have, but you still need to speak with actual people to validate your hypotheses. So you contact maybe 100 people, among which only about 30% reply to you. You ask them if they’re available for a call, and about 50% mysteriously vanish (they have their own reasons). You ultimately set up maybe 10-20 phone calls of 20-30 mins each to discuss. In this context, it’s useful to take notes, because memorizing everything, and all subtleties, is next to impossible. After those calls, you follow up with people and thank them for their time.
In my mind, these are purely business-oriented tasks, which I happen to enjoy doing. Otherwise, I wouldn’t have done them. However, my first love is programming. I love designing and creating new things. I’m fundamentally a problem solver. So if you give me a choice between business-oriented tasks and programming, then I’ll choose the latter anytime. If it weren’t the case, then I would be in the wrong field.
In my post, I admit that my wording sounded like a generalization, but I was speaking mainly from my own perspective. Besides, I happen to know a few programmers, and the vast majority prefer writing code than doing anything else. They may not be naturally business-oriented, but they’re certainly not “business-dumb” (whatever that means). It’s just a matter of personal traits and preferences.
OP, have you taken a look at pytype? we are solving a similar problem, of inferring types without annotations, and would love to hear from you if you’re interested in contributing, or even just to compare notes on our various approaches.
there’s also a mailing list for people working on various python type checkers that you might be interested in.
Thanks for your feedback and the links, Martin. This is much appreciated.
I definitely know pytype - I admire your work a lot!
For the moment, my project is experimental and closed source. I still don’t know whether it will be open source (under which license?), or whether it will stay closed source and shipped as part of a commercial product. My tool isn’t so much for type checking - although it can do that - but instead it’s made to infer various things that current type checkers aren’t able to infer. It will be part of a documentation tool that I’ve been working on in parallel.
I sincerely appreciate your offer of sharing notes, but since I possibly intend to take a commercial route with my tool, I don’t feel comfortable with sharing how it works at the moment.
Anyway, many thanks for your offer. I’ll keep you posted when I release something.
okay, no problem, i can understand not wanting to release details early if the product is intended to be commercial!
Thanks for this post. I always find it valuable to hear about someone else’s learning process, successes and failures, and what they found rewarding.
My pleasure! I had as much fun writing it as you had reading it.