I'm always curious to know whats the motivation behind these kind of side projects ? Is it just to scratch a technical itch ? To build a product for oneself because you are not really happy with anything else on the market ? Learn a new skillset ? Enhance the resume with a new cool project ?
At least for me, side projects are just another hobby. Some do woodworking, some garden, and very rarely is a hobby actually about the product.
Most IT people around me, like myself, enjoy building things. A side project is a good opportunity to do so "just because", without bullshit you don't like - no bureaucracy or approval, no story points, no project meetings, no design documents, writing tests and documentation is up to you. You just sit down, do, and get the feeling of actually making progress in a reasonable time and at the end of the day, having built something. It's energizing.
Sometimes, it is about the product though, and you build yourself a nice tool because you aren't happy with what's out there. Of course, the two goals can often be combined - and at the very least, some useful product is a good excuse to practice the enjoyable hobby.
For me it was to scratch the itch of creation. I live for the buzz of creation. There was also a degree of wanting to see how it was to create an app using the latest tools that I don't normally use, I link to a tweet where I suddenly decide to try and make this app, a flash of inspiration that it should be possible. If it had been more difficult, I would have surely given up and the app would not exist. But it was "easy" enough, and here we are. Plus, the original app has been stuck in my brain for a long time and I remembered it fondly. So, there are many factors... but adding things to my resume is not one of them.
Upbase has a completely different way of structuring all the tools it has to offer. Each tool has its own place, separated from the others. And that creates clarity. In a nutshell, it's more organized and way easier to get started with than Notion.
Great to hear! I know a very meticulous person about to start an EV auto company and this looks like the perfect fit, and I’m 100 percent serious.
It’s a one man idea show with a web of potential add in SMEs on a limited basis but a large volume of subcontracting evaluation and go forward structures for supply chain.
Hope he gets his head around this and finds it a fit. Thank you for sharing. Every tool in its right place helps the shop work efficiently!
Not exactly 30 years ago, but I started my career in early-mid 2000s at a IT services firm. We were working on fixing bugs/building small features for a telecom network equipment of a major multinational (
at that time).
Work was mostly well distributed/planned well in advance and overtime was only around field testing/release dates/acceptance test etc, none of this on demand agile bs that we've these days. Every major/large feature was broken into requirements (or use-cases in some projects) and these were were written by a very senior person (or a group of them) and it would be reviewed for every spelling mistake (I kid you not) before handing it over to the dev team. We used to have workshops where people from different modules (old name for the modern micro services) would sit around a physical table (not a slack/teams meeting) and would pore through the printed document or on their laptop and one person would literally take notes on what was discussed, what were open issues for the next meeting etc. Only when every requirement was completely addressed it would get a green signal to move to dev.
Test / Dev were different teams, and in companies where I worked V model was popular where a test team would write test cases and dev team would write code against these requirements. Testing was a vertical in itself and while devs usually handled Unit/Module testing, system integration testing, field testing, customer acceptance testing were done by dedicated teams. The goal was to capture 90% of defects in MT, some 7-8% in SIT and only 1-2% from field and theoretically nothing post release. We (devs) used to have goals given on how many bugs can be expected from each of the phases to determine our quality of coding. Code reviews had a reviewer, moderator, approver and so on making it a very important event (not the offline bs that happens today). A post release bug would be a nasty escalation on both dev/test teams.
Did I also mention that the MNC had a tech support team who had good knowledge of most systems at high level, worked in shifts and unless there was a bug which required code change, would be able to handle & resolve most escalations from customer. Bugs requiring code change would be sent to the dev team only after a formal handshake between dev and support teams. The bugs would get treated the same way like a feature, and went in maintenance packages released every once in a while (same cycle of dev/testing as features)
There were separate teams in some projects, one for bug fixing of previous releases and one for building new features for an upcoming release and they used to be rotated out after a release !
I always thought that moving to agile/scrum would make life easy and fast. While it shortened release cycles, software quality has taken a huge hit, most code these days are copy/pasted , reviews are mostly lip-service and the end result is that most engineers are forced to do pager duty and are called to fix the mess they made round the clock. Interview processes are mostly focused on irrelevant ds/algo questions and abstract design problems with little to no emphasis on a candidate's experience. I had one interviewer tell me that they really don't care about a candidate's experience but only his performance in the interview matters (yeah, no sh1t sherlock, explains why the company needs 24x7 on call dev support !)
Call me old fashioned, but I do miss the old way of building boxed software (plan/analyze/design/code/test/ship and maintain). Work was relatively more predictable and office felt like a place where people actually collaborated and worked together to build something they could be proud of !
Eating is not just to survive, human body is not an automobile that you fill gasoline in and make it work. If thats the expectation, then whats the difference between a human and a machine ? Buying food, cooking it, or baking a nice recipe you found, sharing food with friends, calling over your friends/family to dinner, having a nice meal with everyone, these are all interactions that makes us human. Get rid of all of them , then humans are not "living" anymore, they are simply "existing".
You could still live without those food rituals if you replace them with other means of human interactions. Instead of sharing a meal, you could also go on a hike with friends. Is there something essential to a meal that cannot be replaced?
Though in principal I agree with you. Food is a pivotal point in life. Which makes me wonder: How much is our life determined by the rituals that surround food?
Eating is the main source of social aggregation in the small group. It's the phisiological nature of the gesture, the biological need to eat, that brings everybody to the same table where the resource is.
Also cooking is a ritual, that prepares you to the meal with smells, sight, hunger. It also makes you relax. Try that, if you don't actually cook yourself your meals.
The reasoning provided by someone to me was that at a org level, it's more cost effective for the org to replace those 1-2 departures with the market rate salary, than raise the salary of the whole team to the market rate.
Many people stay back in a company even knowing they could probably get more if they try else where (ex: work like balance, friends, job security in the long term, exciting work etc). When a org has sufficient no of such ppl, it doesn't matter to them when they lose some 1-2 start performers. Also, there's no guarantee those star performers would stay back even if they are paid higher salaries !!
Maybe a wild guess, but anything thats not related to ads/marketing/analytics etc., are too difficult to monetize by a solo founder ? Or maybe the other areas too difficult to get into not just in terms of software complexity, but in terms of support requirement , availability SLAs etc ?
If you know c#, then .net6 released recently, which is a LTS release and has really cool features like hot reload, minimal API etc. It also has sufficient performance improvements as compared to its predecessors. As a language, personally I find C# to be much easier and better to use as compared to java/python, especially for web dev and C# 10 has some really good language improvements like record types etc. I have used it mostly in windows env, so, not sure about it's performance on Linux, but considering its cross platform, I'm guessing it would be good.
Honestly, I've yet to find a backend that is as productive and performant as C# + Entity Framework out of the box. I've tried a wide array of other products, but somehow for ease of use this really sticks out. Of course scalability maybe be in an issue in the long run with EF, but I don't know if simplest and scalability really go hand in hand.
