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 ?
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".
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.
I read this somewhere that, instead of focusing on "what to do ?", shift your focus to "why do you need to do it ?". If you focus on the why and can convince yourself on the importance of it, maybe it would get done. On the other hand, if your "why" is shaky, then most probably somewhere in the back of your mind it's marked as "not important". It's like one of those things that you just want, but don't really "need", so no wonder you lose interest pretty soon.
I'm surprised at the no. of recommendations for resharper even now. I thought most of the new features of resharper was already included as part of VS2019. Any specific feature that's missing ?
Yeah, sometimes I do fall in this vicious circle of overwork / decrease in productivity. Trying myself to get out of it, but the stress/anxiety surrounding a deployment/making a mistake is way too high for me to decisively get out of it.
1. If you want to do something but not able to do anything about it, maybe its not something you "want" to do. It's like swimming against the tide, it'll always be hard. So, instead find something you "want" to do. For ex: deep down you might enjoy painting, but looking at an article on how some programmer made millions by selling his startup, you might be tempted to try your hand at coding. But no matter how much you motivate yourself, your mind will continue to resist when the implementation phase comes, as, deep down, that's not what you are interested in.
2. When you start a project, don't spend too much of time on planning/research. Any project you start, try to finish atleast the most important parts of it while your initial enthusiasm lasts. If you spend most of your initial enthusiasm on planning/research and other stuff, you'll have little energy left for implementation. Start and course correct along the way.
Thanks for your comments. If I understood you correctly, you want the comments marked as TODOs listed in a UI automatically , which you can track/move around. Am I correct ?
Something called 'integration testing' that has to be done before the final build which clearly flags off any compatibility issues between components.
Every component comes with a major/minor release no., which tells about the nature of change that has gone in. For ex: Major rel is incremented for a change that usually introduces a new feature/interface. Minor release no are reserved for bug fixes/optimizations, that are more internal to the component.
The build manager can go through the list of all the delivered fixes and cherry pick the few which can go to the final build.
I've seen people doing the same in South Korea, where people used to travel from a whole other town to work. They used to leave office around 10 in the night, and would be back in office by 7:30 AM the next day. I used to wonder if they even slept !
Even here at Bangalore/India, I spend close to 3 hours in travel. Fortunately I've pick-up/drop facility to office from home. So, I just sleep in the office cab.
It's only strange until you get used to it. Once you are used to the travel routine, you can start to explore newer ways to make the commute time more productive (reading/writing a book, learning a new programming language, taking a power nap etc).