It's a React+Relay single page app talking to a Django-backed GraphQL endpoint.
Django's ORM helps a lot with cleanly serializing the filters. Though we denormalize the label/transaction relationship, since live-filtering everywhere in the app kills performance.
"Trying to use all the features of a language and thinking a one liner is cool even when a five liner and a one liner is same when compiled into machine code"
Thing is, it's pretty easy to code for a machine. It's REALLY hard to program in a way that other developers can understand you. And, like in literature, using less words to describe something is more often better for the reader.
"Too much jargon, falsely claimed software engineering practices and overly zealous object oriented mentality"
I used to hate all the jargon too but then I realizes it gives programmers a vocabulary to discuss things. When everyone understands the jargon, it makes discussing complex solutions a lot easier.
OO can definitely be overused, but honestly 99% of the problems I face are people just writing unmaintainable, procedural code. You're right though, OO can often be less simple (harder to read all at once) but that's the trade off we devs need to balance when writing code.
I don't want to sound condescending but is it possible you are making excuses for learning hard things. Maybe it's the people you work with who are pushing it down your throat the wrong way. Maybe you already know these hard things but just haven't had to use it so you're giving up on the ideas. Or maybe I'm still in the cynical phase of my life.
> Thing is, it's pretty easy to code for a machine. It's REALLY hard to program in a way that other developers can understand you.
I feel this statement is way too subjective and has been used very often in the industry in a negative way. Just because one does not understand the depth of the problem or style doesn't necessarily mean the style is bad or the solution is bad. I first realized this when I picked up AOCP.
> OO can definitely be overused, but honestly 99% of the problems I face are people just writing unmaintainable, procedural code.
I've seen unmaintainable OO code and maintainable procedural code.
> OO can often be less simple (harder to read all at once) but that's the trade off we devs need to balance when writing code.
And it's often vague when rules of maintainability pops up somewhere and people try to pick that up. Suddenly, it feels like there is no need of "Science" in CS.
> I don't want to sound condescending but is it possible you are making excuses for learning hard things. Maybe it's the people you work with who are pushing it down your throat the wrong way.
May be it is the people but then you have to deal with people in the industry. Not too sure about what you mean by "hard things". The hardest problem I've faced at work was the interview question (in a Fortune 500).
I'm surprised that no one mentioned Functional Programming languages. I think the way they think would be quite refreshing for someone get bored of OO.
This is awesome! What made you build this, I would have thought the market were too saturated? Have you considered blogging about your process? Would love to hear about what marketing you did to achieve where you are at today.
Thank you! Honestly, I built Invoiced because a lot of people using this invoicing website I made [1] kept asking for more features and offering to pay for them. Initially I was hesitant about building a product that already had competitors. Fortunately the target market is huge because we solve problems faced by most businesses. Many of our competitors have built full-stack accounting platforms whereas Invoiced focuses on building and maintaining your revenue stream.
I might take a break at some point to blog about my experience. It's been an incredible journey so far.
While I agree that pg's example is a bit extreme, the point still stands. At the beginning stages, great design won't determine the success of the product. Having customers will. So time and money is better spent in other areas. This isn't to say they won't come to you eventually when a better design is needed. Great design is still important, just not at the stage this company is at.
> At the beginning stages, great design won't determine the success of the product.
People hear 'design' and just think it is just the prettification of a product and not the actual usability and utter simplification of it. Maybe it's because there are so many designers that focus on gradients and drop-shadows anymore instead of the what and why, but design is imperative to the success of a company. Even though PG's point was that it doesn't matter (if I understood it correctly?), Google's minimalistic homepage compared to other search companies' sites in 1998 (bold colors, links everywhere, multiple functions/offshoots of the site) is part of what made it so popular; it did what it said on the tin and it made sense doing it.
I highly recommend the book "Making Software: What Really Works, and Why We Believe It". It's a collection of essays showing statistical studies on certain software techniques.
100% agree. So many blogs and books talk about how X is better than Y, or how Z is bad, but it is usually just a gut feeling with very little data to back it up. This book on the other hand is chock full of actual data on many topics that are debated all of the time. If you only read one programming book this decade make it this one. For me it replaces mythical man month as one of those books I now expect others have read if they want to debate the topics it presents.
Interesting, not to get too off topic here but is there a reason you didn't use a 3rd party service for billing like Paypal or something? Sounds like you went 90% of the way and stopped at the last 10.
More like the last 1%. Implementing the billing system would have been trivial. It was a mental block. I just didn't want to completely commit to the business I created.
No license but I'll throw a BSD license on there later if anyone wants to use it.
Update: It's been a while but I think when I left off I was working on a bug in the Bayes module. The concept was new to me at the time and I was still wrapping my head around it. Also I'm sure the email parsers are out of date at this point.
Basically the whole project was an excuse to learn Bayes rule and use Lamson. Plus people wanted to pay me for it. But once I got the code out, I quickly lost interested as explained above.
After this I learned you need to price it for the entry level PR folks to pay for it. Honestly I learned so much after this I think your best bet would be to pick up the phone and chat with PR people to fill in the gaps where I left off on the blog.
After implementing the billing system I was thinking of pivoting out of the PR agency market and into small businesses (who do their own monitoring). I was also looking at ways of gathering alerts without actually using Google Alerts and blatantly violating their TOS.
Great article with lots of valuable info in there. The part about the actual whiteboard is almost irrelevant. Most of the comments here are getting too worked up about that.
"Learn Python and use it during your interview."
Python is expressive, a high level and kind of writes like pseudo code. Just write pseudo code. The point isn't syntax anyways.
"The highest value problems I know of are on Project Euler."
I do enjoy running through Project Euler problems but I have no evidence that's making me better at my day job, only better at answering Project Euler problems.
Many companies (including the one in question) want to see actual code in a language that they use at the company. The fact that Python happens to look like pseudo-code is a bonus.
Maybe you already knew all the lessons in Project Euler, but for me, I became a much better programmer. How elegant are your solutions? Have you tried writing them in a different style than you're used to? Say, in a functional style? With Haskell?
But if companies want to see actual code in a language they use, then learning python to use simply for interviewing wouldn't really work either right? So your only options would be "use any language but not just pseudo code" or interview for python jobs only.
Oh no, I certainly didn't know all the lessons and I haven't done all of them.
"How elegant are your solutions? Have you tried writing them in a different style than you're used to?"
That's a great point, so I suppose it's less about the actual Project Euler problem, and more about optimizing, refactoring and trying them in different languages.
> That's a great point, so I suppose it's less about the actual Project Euler problem, and more about optimizing, refactoring and trying them in different languages.
I had a different take on the article than most of the comments I've read. It's about keeping your word. If You say you're going to do something then DO IT. If you don't want to be seen as a joker then you just have to keep your word.
I see it like this. If you make a timeline yourself and find you won't be able to keep it then you have 2 options. 1) Let the person you promised know right away or 2) "find a way. Or make one" - do what you got to do to get it done.
Sebastian is highlighting the second option because it's already passed deadlines and shit sounds like it's getting serious.
If you want to be respected, loved and an effective leader. Keep your promises. Every single one of them. (Or, in true Machiavellian form, at least make sure it's perceived that way.)
Steve Jobs inspired me on so many levels. Whenever I need a boost I find myself watching one of his incredibly powerful talks, oozing with inspiration. The man accomplished more in an hour than most will their entire lives. This is a hard loss for our entire industry.
Writing as little code as possible to fully accomplish a goal has recently become a fundamental principle that I live by.
If I can write a piece of code in fewer lines, I'll do it. That pretty obvious, we all would. But I try to take it a step further and consciously seek solutions that lead to fewer lines of code. Chopping down a large block of code is an incredibly gratifying feeling for me.
I find that writing less code while maintaining expressiveness usually leads to simpler solutions and, IMO, it is simplicity that reduces the bug count.
I find that in a team environment that I would prefer my co-workers write more lines of code, and longer lines at that.
While, given a moment or two, I can unpack a dense list comprehension (a one liner) I would rather read several statements that add up the same thing.
Of course there are many times when you could do the same thing with fewer lines, in a more elegant, straight-forward way. However I have a hard time believing that just having fewer lines is a sufficient goal for flexible, maintainable code.
