# experience report Published articles for experience report. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Obsidian Migration - One Week Later DevFeed: [The Obsidian Migration - One Week Later]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2025-03-17T05:38:37Z Content type: article Language: en Sources: [Posts on Harsh Shandilya]() Topics: [Obsidian](), [migration](), [GitHub Copilot](), [Code](), [Python](), [Mobile]() Tags: [code](), [experience-report](), [github-copilot](), [logseq](), [migration](), [mobile](), [notes](), [obsidian](), [python]() ### AI overview An experience report about moving from Logseq to Obsidian after a week. The author describes using a Python script, developed iteratively with GitHub Copilot, to migrate dates and tags, and notes that Obsidian plugins also work on mobile. ### Source excerpt An experience report of using Obsidian for a week, coming from a year of Logseq ## My Answers for Microservices Awkward Questions DevFeed: [My Answers for Microservices Awkward Questions]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-03-15T21:48:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Microservices](), [Development](), [Software Engineering]() Tags: [coupling](), [experience-report](), [independent](), [microservices](), [software-development]() ### AI overview An experience report about developing several small, independently deployable codebases that collaborate to provide a single user experience. The author explains that reducing accidental coupling, rather than adopting microservices as a goal, motivated the approach, while noting that the choice involves tradeoffs and is not universally applicable. ### Source excerpt Earlier this year, Ade published Awkward questions for those boarding the microservices bandwagon. I think the list is pretty solid, and (with a small push from Ade) I decided to write concise details on my experience. I think it's reasonable to start with a little context building. When I started working on the application I'm primarily responsible for microservices were very much fringe. Fred George was already giving (great) presentations on the topic, but the idea had gained neither momentum nor hype. I never set out to write "microsevices"; I set out to write a few small projects (codebases) that collaborated to provide a (single) solid user experience. I pushed to move the team to small codebases after becoming frustrated with a monolith I was a part of building and a monolith I ended up inheriting. I have no idea if several small codebases are the right choice for the majority, but I find they help me write more maintainable software. Practically everything is a tradeoff in software development; when people ask me what the best aspect of a small services approach is, I always respond: I find accidental coupling to be the largest productivity drain on projects with monolithic codebases. Independent codebases reduce what can be reasonably accidentally coupled. As I said, I never set out to create microservices; I set out to reduce accidental coupling. 3 years later, it seems I have around 3 years of experience working with Microservies (according to the wikipedia definition). I have nothing to do with microservices advocacy, and you shouldn't see this entry as confirmation or condemnation of a microservices approach. The entry is an experience report, nothing more, nothing less. On to Ade's questions (in bold). Why isn't this a library?: It is. Each of our services compile to a jar that can be run independently, but could just as easily be used as a library. What heuristics do you use to decide when to build (or extract) a service versus building (or extracting ## Experience Report: Weak Code Ownership DevFeed: [Experience Report: Weak Code Ownership]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-02-23T15:00:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Code](), [Software](), [optimize]() Tags: [code](), [collective](), [developers](), [experience-report](), [opinions](), [optimize](), [team]() ### AI overview The author reflects on moving from Collective Code Ownership to advocating Weak Code Ownership after experiencing disagreement and reduced productivity on a team of senior developers. The article argues that talented developers often work in incompatible ways, making it difficult to optimize a shared process for everyone. ### Source excerpt In 2006 Martin Fowler wrote about Code Ownership. It's a quick read, I'd recommend checking it out if you've never seen it. At the time I was working at ThoughtWorks; I remember thinking "Clearly Strong makes no sense and I have no idea what scenario would make Weak reasonable". 8 years later, I find myself advocating for Weak Code Ownership within my team. Collective Code Ownership (CCO) served me well between 2005 and 2009. Given the make-up of the teams that I was a part of I found it to be the most effective way to deliver software. Around 2009 I joined a team that eventually grew to around 9 people, all very senior developers. The team practiced Collective Code Ownership. Everyone on the team was very talented, but that didn't translate to constant agreement. In fact, we disagreed far more often than I thought we should. That experience drove me to write about the importance of Compatible Opinions. I still believe in the importance of compatible opinions, but I now wonder if the team wouldn't have been more effective (despite incompatible opinions) if we had adopted Weak Code Ownership. The 2009 project heavily shaped my approach to developing software. I suspect I'm not the only one who (at one time) believed: if we get a team full of massively talented people we can do anything. It turns out, it's not nearly that easy. Too many cooks in the kitchen is the obvious concern, and it does come up. However, the much larger problem is that talented people work in vastly different ways. Some meticulously refactor in small steps, others make wide reaching and large changes. Some prefer one language to rule them all, others are comfortable switching between 12-15 different languages in the same day. Monolithic vs separated codebases. Inherited vs duplicated config. It goes on and on. You try to optimize for everyone, to ensure everyone is maximally effective. Pretty quickly you run into this situation- If you optimize everything, you will always be unhappy. --Donald Kn ## Year Five DevFeed: [Year Five]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-04-30T12:00:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Job](), [Software Engineering](), [engineering-culture]() Tags: [clojure](), [developers](), [employment](), [experience-report](), [job](), [retention](), [software-engineering]() ### AI overview This experience report discusses why software developers may leave an employer after roughly three or four years. It describes perceived limits, familiarity with one's existing code and opportunities elsewhere, compensation differences, and the appeal of new challenges, while noting that the premise is speculative and based partly on personal observation. ### Source excerpt The average lifespan for a software engineering job is 4 years. Okay, I've never actually seen proof (or contradiction), but that's the general feeling in the groups I associate with. Perhaps that's selection bias - my employer has generally changed on year 3 or 4. Perhaps this is the exception and not the rule, in that case feel free to simply read this as an experience report. However, I do think it's somewhat common for developers to leave around year 3 or 4. This entry contains speculation on why they leave, and offers one idea on what employers can do to break that cycle. My 4 year employment cycle generally looks like this Year One: "I'm in over my head. My semi-bluff was in-fact a bluff. They're going to fire me any day." Year Two: "It's nice to feel like a productive team member" Year Three: "This is fun, and I'm not bad at it. It's satisfying to pass on knowledge to teammates." Year Four: "This feels repetitive, that grass over there sure looks greener" I expect that I, like many programmers, probably undervalue my contribution in the early days and overvalue my contribution in the latter days. In Year Three and Four at DRW I spent some time thinking about how I felt, and observing the behavior of some colleagues that were also on year three and four. A few things stood out to me. A company you don't work at always seems to have infinite possibilities; however, after a few years with an employer, it's extremely clear what your options are. More importantly, it's very clear what limitations will likely always be there. A company you don't work at contains no code you're responsible for. Conversely, any company you've been with for 4 years probably has plenty of code you're not proud of. If you're responsible for that code, it's a constant reminder of your previous limitations. If you're not responsible for it, your co-workers aren't likely to let you forget about it anytime soon. There's always someone willing to pay you more than you're worth. After several