Why Developers are Switching to Mac - <AUTHOR> http://www.smashingmagazine.com/2009/04/26/five-reasons-why-designers-are-switching-to-mac/ <comment><USER2> And here: Why many developers are _not_ switching to mac.

1\. Abysmal window manager, not replacable. Pixel waste, clumsy (long list here)

2\. Mandatory Click-to-Focus and Click-Raise. Showstopper.

3\. No home/end keys on apple laptops and other wierd layout choices.

4\. Nasty BSD gang-rape under the hood. Yes, OSX has it's own "windows registry".

5\. Idiotic shareware culture that makes you pay for the smallest things. $10 for a sane Macbook trackpad driver that should be in the OS in first place.

6\. Inconsistent keyboard shortcuts, meta-key nonsense, Apple+Q.

7\. Menus only on context-sensitive titlebar, sub-problem of #2

8\. Single mouse button idiocy.

9\. Finder.

10\. Equivalent PC hardware can be had for 60% of the apple price

<comment><USER3> you say tomato i say tomato. the things you've listed aren't deal breakers for me. i've developed for a number of years now on all three systems and so far mac laptops take the cake easy. that's just me situation, though.

also, -1 for use preformatted text that ruins this whole discussion for everyone (without a wide browser window).

<comment><USER4> >All three systems

What does this mean?

<comment><USER3> nix (athena, redhat, debian, ubuntu), windows and mac. i've done some development on sparc, too, but i never felt comfortable.

yeah, i wrote the comment quickly and didn't catch my 3-os assumption

probably you could have figured this out, though :-)

<comment><USER4> Oh.

Sorry, I've been spending a lot of time around BSD lately. What I was asking was if you meant "Windows, BSD, Mac" or "Windows, BSD, Linux" or what.

</comment></comment></comment></comment></comment><comment><USER5> More like '5 reasons why Mac is no longer impractical for developers'. I think the only absolute benefit it offers (which is driving some people to it but curiously isn't mentioned) is being able to develop iPhone/iPod apps.

Not hating on the Mac, or anything - competition is a good thing. I just didn't care for the evangelista tone.

<comment><USER6> The majority of this article seems to be the standard " OS X is Great!" talking points.

In my opinion, the real reason that developers switch to OS X is so that they can develop software for apple products (or in the case of web development, develop websites that are OS X friendly).

<comment><USER7> None of the "advantages" sounded so hot to me except the desktop effects, which I haven't bothered to enable in Ubuntu anyway. I use a Mac regularly, and the interface hasn't stopped irritating me. I hate the stoplight window controls, and I hate using Command instead of Control. I love Apple's hardware design, but the software feels... obtuse. And apathetic. Like it has a hard time paying attention to me and doesn't feel like being helpful anyway. (I bought my Mac for four reasons: to try iPhone development, to run Adobe Lightroom, because I love my iPhone, and because I wanted to see what the fuss was all about.)

I'm positively drooling for Apple to release a tablet PC, though. Gimme gimme gimme _please_.... The multitouch stuff on the iMacs looks extremely cool, and you just know Apple will nail the tablet.

<comment><USER8> There is absolutely no proven market for a 'tablet PC'. None whatsoever. Despite them being available for years in various forms.

<comment><USER7> Because they're all terrible. They're all just small laptops with touch- sensitive screens and a few touch-screen software features. I've been itching for a tablet PC since at least 2003, but I've never bought one because I want one that doesn't suck. (Wait, I did buy a Nokia n800... sigh.) Apple's tablet won't suck, because Apple will 1) put a lot of work into creating a UI that works well with the form factor, and 2) have the guts to cut hardware features if that's what it takes to create a decent product.

Funny, I sound like an Apple fanboy, even though I came here to express my irritation with OSX. Right now, if somebody gave me an iMac, my first impulse would be to install Linux on it, but you just have to look at the non-Apple phones released since the iPhone launched to see that Apple is on a completely different plane when it comes to smaller devices. I can't wait to see what they do with tablets, though perhaps it would hurt their prestige to release a novel product for a small market... they wouldn't be able to keep the hype within reasonable bounds, and expectations wouldn't be met.

<comment><USER8> The iPhone works, because it's small enough to hold with one hand, while you type with the other.

I can't see anything much bigger working TBH. At some stage, you need a keyboard to type on, and to hold the screen at a good angle. And then it's not portable so you may as well have a netbook/laptop.

<comment><USER7> I typically move my 15" ThinkPad around by grabbing about (checking...) four inches of the corner with one hand. I admit it's a strain to hold it up and type with the other hand, but a tablet would be lighter and more compact. The ThinkPad is heavy and has a long lever arm.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> These are actually reasons why casual, non-developer users are switching to Macs, not developers or designers.

The author describes how OSX is more open-source friendly, describing also how it comes bundled with developer tools, but I find it incredibly hard to believe that an actual developer will have a hard time finding a better tool online. The apps that come with the OS aren't exactly the best, and just about everyone who's planning to get some work done will find other tools wherever with better libraries and more support.

The author also goes on and on about the UI. The simple taskbar in Windows and Linux is enough for me. Is it really necessary to have to view a thumbnail- esque to change to the window? Alt-Tab is enough.

Security? Please! I'll say again: the developers I know are not stupid. Anyone in their right mind and with some knowledge of computers should know that clicking on an odd-looking ad, or downloading a strange attachment, or accessing a crazy porn site aren't sane things. A combination of Firefox and AdBlock/NoScript can make any OS safe for most people. Unless you have kids who have thumb drives and like to use your computer, contracting a virus that way shouldn't be a concern, either.

The hardware-specific optimization is another problem. iPhone development is booming right now, but what about the rest?

I'm willing to accept "the apple", but presenting bogus arguments isn't convincing.

<comment><USER10> > The author also goes on and on about the UI. The simple taskbar in Windows > and Linux is enough for me. Is it really necessary to have to view a > thumbnail-esque to change to the window? Alt-Tab is enough.

I would argue that -this- is the reason why Mac is converting casual non- developer users. "Normal people" are complicated and the way they perceive files, windows, and apps interacting on a computer is varied and bizarre. Alt- tab is simply not enough for normal people to connect with a computer the way they expect it to work.

Leopard has come really far in making visualization tools that are fast, easy to understand, and useful. With one keystroke, I can interact with my open windows in 5 different, task-focused ways. With two keystrokes, I gain access to even more.

</comment></comment><comment><USER11> If you develop web based applications, Mac OS X has many limitations, strangely enough.

Mac OS X is UNIX alright, but to pull most of libraries from MacPorts is the only sane way to manage dependencies.

If you run Tiger (and see no reasons to upgrade) - then you are stuck with old Java release for ever. There is no way to upgrade Java other than buying Leopard, and then you are still at Apple's mercy for future upgrades.

A simple task like doing 'sudo emacs' requires some custom shell scripting, since emacs that came with the operating system is old and useless.

My initial excitement about Mac hardware is also dented after battery and graphic card both failed only after a year on my MacBook Pro.

A web developer would be much more happy on Linux if he/she could live without eye candy.

<comment><USER12> "Mac OS X is UNIX alright, but to pull most of libraries from MacPorts is the only sane way to manage dependencies."

The only time this is the case is ImageMagik. Everything else is easily manageable by hand unless you insist of mixing it with the normal mac stuff. MacPorts is hardly _necessary_.

It's unfortunate too, because Apple has one of the _best_ non-package solutions for managing software installs in their .bundle and .app and .framework scheme. It's exquisitely simple and elegant, but everyone seems hesitant to adopt it because, well, because the UNIX way is to use a byzantine and barely functional package system and not incur manifest parsing penalties when apps are loaded.

<comment><USER13> Last time I tried to pull ImageMagik from MacPorts it tried to install X. Huh?

<comment><USER14> same thing happened to me. imagemagick has an image viewer app that requires x11.

worse, i did indeed already have x11 installed, but imagemagick didn't like it for some reason, and failed to install. so i pulled down one of the binary distributions instead.

</comment></comment></comment></comment><comment><USER15> I'm not sure why a 'unified interface' is such a selling point. Does Windows not offer it? To be honest, I'm constantly finding that things on my Mac don't have a unified interface and that Apple keeps changing what they're looking to build.

Both platforms (Mac and Win) tend to violate consistency on a case-by-case basis. Adium, one of the apps highlighted in the article as awesome (which it is), does not conform to the rest of the system's interface. Specifically, it uses white tabs rather than the new not-quite-metal look of 10.5. Likewise, iTunes has different scrollbars, Camino and OmniWeb don't use the new button- look for controls and use the old-style flat color images, sometimes input boxes have rounded corners and sometimes they don't, sometimes you can tab to select menus and sometimes you can't, find boxes are in every form imaginable. . .

Consistency is great, but practicality beats purity. Both Apple and Microsoft have kept things decently consistent and violate their designs. Heck, with web pages throwing all sorts of interfaces at users, even the non-techies are getting used to understanding how different interfaces work.

OS X is great, but I don't see it as being amazingly more consistent than other platforms.

</comment><comment><USER16> I think this is an extremely poor article, particularly as this largely seems like just a random selection of vague talking points while giving anything concrete. I'm slightly frustrated that people think that this sort of article is worthy of being upvoted when it has little more substance than "Apple! Yay!".

I think the real reasons developers, compared to all other users, are beginning to use Macs is down to 3 reasons:

* Unix tools, software and terminal. Unix, and Unix software, is the bread and butter for a lot of developers, and getting them to work on Windows is pain and even then is regarded as a second-class citizen. People have been crying out for a truly good Unix workstation for years, but Apple are the first ones to gain enough traction to matter and truly create a good out-of-the-box user experience for it.

* Universality. Mac OS X runs notoriously poorly under virtualization, so buying a Mac is the only simple choice if you wish to develop for all current platforms, something that is increasingly common, and run all the software available.

* Fashion, particularly in areas where programming has overlapped design such as web development. People follow each other and their trends, and Mac OS X and the Macbook Pro has become a fashion among a certain type of developer.

<comment><USER17> Have you even read the article? Your first two points are mentioned prominently.

<comment><USER16> Yes, I have read the article. Yes, they are mentioned in the article... alongside another dozen Macintosh features which have little or no bearing on the reasons that developers specifically buy Macintosh machines compared to ordinary users. Unless, of course, you honestly think developers are buying Macs because of Quartz or Core Animation as much as they are Unix support, because they aren't savvy enough to know how to avoid spyware, or because they're looking for obviously much-needed help at the Genius Bar. A stopped clock is right twice a day.

</comment></comment></comment><comment><USER18> I picked up a 13" Macbook (unibody) at the end of last year because I was looking to do some iPhone/iPod Touch development. I'd always wanted to give OS X a go because of the underlying system and I've become a big fan of the OS.

I'd have to say that the biggest thing holding me back from doing extensive development on the OS, though, is the lack of "Home" and "End" buttons (it's the small things, I guess). I know there's Command+Left/Right but it's just such a weird keystroke and if I want to select a line it's not End, Shift+Home. I have to press Command+Right, Shift+Command+Left and it just feels like a lot of unnecessary keystrokes.

I also don't like the fact there's no built-in solution for mouse acceleration. I want it turned off but from what I've read in my searches there's no way to do it without running a separate program to do it for you.

<comment><USER19> Text editing on the keyboard also drove me crazy for a while. You do get used to it. My lingering complaints: the insane placement of Cmd for Cut/Copy/Paste (talk about a Vulcan Nerve Pinch!) and the mental shift required when switching back and forth between the GUI and the shell. (Mainly that's remembering to switch to/from Control/Cmd).

<comment><USER20> But that's the best bit!

I love using Command-C to cut and paste throughout the OS including the terminal, rather than having to switch to Control-Shift-C for certain things as you do under Gnome, where forgetting means canceling something.

</comment></comment></comment><comment><USER21> I've come to like my iBook G4 more since I've been running Debian on it. The advantage, which no fanboy can dispute is this, free upgrades. I got sick of this or that not working under 10.3 (no Java updates, for example) and so I thought "I'm just not shelling out $100+ for a new OS."

I do appreciate that OSX is now an official UNIX, more power to 'em.

<comment><USER22> I also have an iBook G4, what are my choices to install Leopard for free? Torrents?

 _I want it for iPhone development so linux is not an option._

<comment><USER23> This isn't a Warez approval site so stealing it is not an option. Therefore your choices to install Leopard for free are: Find someone willing to fund your purchase of Leopard.

</comment></comment></comment><comment><USER24> What about brand appeal. Macs are also a status symbol. A way to make a statement about yourself, telling others that you are 'in' that exclusive club, you are cool and happening.

<comment><USER12> I really think that this is an overstated effect for computers. For the iPhone and iPod maybe that's true. But for the laptops? I dunno.

I know OSX is the #1 reason I prefer a mac at home. Being able to play like a native member of the Posix world while still having one of my favorite GUI APIs available is a big deal in my book.

<comment><USER7> Opening up a laptop in a coffeeshop is like a peacock spreading its feathers.

<comment><USER25> Oddly enough on the lekking[1] front; I've gotten more comments in the last few months when I pull my smallish (8.9in.) netbook out and use it, than I've seen anyone get for using a Mac in the past couple of years.

1\. Lekking - A gathering of males engaged in competitive mating displays <http://en.wikipedia.org/wiki/Lekking>

</comment></comment></comment></comment><comment><USER26> Blah, they need to reword "Developers" with "Web Developers".

A systems or applications developer won't switch to OSX for those reasons at all (for other reasons maybe).

</comment><comment><USER27> I read this and was underwhelmed.I'm not a Mac hater (I used one for over a decade), but nothing on the list seemed all that compelling. The Unix base and virtualization are the most compelling reasons, but the only reason virtualizing Macs on generic x86 boxes is problematic is OS X's license.

Macs are nice machines. But if you have some other reason for using Windows (cost, compatibility, prior experience), I don't see a compelling case for switching.

</comment><comment><USER28> I didn't read the list in detail, but was there realy anything on that list(except the hardware and the mac only apps) that i don't have in KDE4? Im seriously asking and im not really bashing apple this time(i sort of have a history with that).

</comment><comment><USER29> I like the Macbook Air except for the glare type display. And im not sure how well it supports linux.

Currently i think about buying one of the sony vgn-z notebooks. Any expriences with these?

<comment><USER30> There is an ~$50 filter which sticks to the Air's display, converting it into an approximately normal (non-glossy) one.

</comment></comment><comment><USER31> nice article. I have to admit, that after Apple and Intel "teamed" up I actually spent a thought on buying one, but my wallet was clearly against it since I'm a full time CS student. perhaps sometime in the future I'll buy a mac or I'll give OSx86 (<http://www.osx86project.org/>) a try.

</comment><comment><USER32> I do despise animation in user interfaces. When I click a window I want it to just appear and not spend 3 seconds animating.

I don't like OSX but I am not going to deny it's power or appeal.

</comment><comment><USER33> Both operating systems are comparable, each with their own pros and cons and neither OS has a killer feature nor a debilitating feature.

Just find what works for you.

</comment><comment><USER34> I buy Macs because they work fine and I can afford them and I spent far too many years of my life dicking around with Linux on the desktop when it clearly belongs in the datacenter.

I don't use Windows because it isn't Unix, not even if you use Cygwin and squint and tilt your head sideways.

<comment><USER35> If you spent too many years dicking around with Linux you have been doing it the wrong way.

<comment><USER34> > you have been doing it the wrong way.

You ever stand behind a door because you were afraid the modelines in your XFree86 config file were going to blow up your monitor?

Uphill both ways in the snow, etc.

<comment><USER35> There was no easy to use Unix in '96

<comment><USER34> There still isn't. Unix is hard.

<comment><USER35> No it's not. My 13-yo son uses a Linux-based phone, my wife uses a Mac and my mother uses Ubuntu. It's fair to say neither of them uses the terminal for anything (wife did sudo shutdown her Macbook when it refused to do it from the Apple menu), but Unix is not about terminals - it's an operating system ideal.

</comment></comment></comment></comment></comment></comment><comment><USER36> <http://www.paulgraham.com/mac.html>

<comment><USER37> From the notes:

"Y Combinator is (we hope) visited mostly by hackers. The proportions of OSes are: Windows 66.4%, Macintosh 18.8%, Linux 11.4%, and FreeBSD 1.5%. The Mac number is a big change from what it would have been five years ago."

I'd love to see current numbers so we can spot the trend

<comment><USER38> Agreed... those numbers were from March 2005. PG, can we have an update, please?

Also, I was at the first Startup School at Harvard in 2005 (?). One of the speakers (PG?) noted the very high proportion of Macs in the room. Looking around I guessed about 80%. That is consistent with something PG said in that Mac essay - "If you want to know what ordinary people will be doing with computers in ten years, just walk around the CS department at a good university. Whatever they're doing, you'll be doing." I'm seeing more of my friends and coworkers using Mac, even DBAs who use MS SQL Server a lot.

</comment></comment></comment><comment><USER39> Vista.

Edit: OK, how am I wrong?

<comment><USER40> It's your argument, the burden of proof is on you. I would imagine that's why you got all the downvotes.

</comment></comment><comment><USER41> Although I haven't read any of the 56 responses here, I'm probably safe in assuming:

1) No new insight into this earth-shattering issue will arise, even from the mighty minds on HN. 2) Even if 1) were wrong, it wouldn't change anyone's mind anyways.</comment>


Ask HN: Solo devs, how do you plan your development? - <AUTHOR> I'm wondering what framework do you use to plan your product development.
Right now I'm using just Trello with a 4 lists, Planned, In-progress, Staging and Production. Works ok but I feel I can do better, like adding a progress % or something to get a better overview of my tasks.
Are you using any agile framework that's simple and good enough for a solo dev (and maybe to support a team of max 3 more devs in the near future)? <comment><USER2> Many comments are focusing on kanban procedures, but the most important parts of solo development for me are social milestones. For example...

* Who will I show X feature to?

* When will I show it to them?

* Can I show them a draft?

To me, the biggest risk of solo development is not how I manage a todo list, but that I'll build the wrong thing, because I waited to get feedback.

Some things that have helped me a lot...

* set up a time to show someone your progress on feature X before you feel totally ready to.

* ask someone to try and pick up and tweak some layer of your code (or pair with them)

* if you are developing a library--record hour long screencasts where you use it in a realistic way. Prioritize issues where you say, "oh, I should fix that...". Repeat but with another person driving.

I use github projects and a calendar (the calendar appointments feel more important!)

<comment><USER3> This is really good advice even if you are not a solo dev. A lot of devs that I have worked with (and this includes me at times) come with the expectation that they will be handed a task with a list of requirements, and all they have to do is check off the boxes and turn in the code. If QA found no bugs, then it's good.

Even when things really are that clear cut, junior developers still often need a lot of feedback that they are on the right track. Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it.

Maturing to the next stage requires that you be comfortable working in situations where the requirements are not clear or set in stone. At that point, your objective is not merely compliance with the spec (if there even is one) but that the code solves the problem as intended. Since developers are rarely in a situation to determine that for themselves, you have to become comfortable again with asking for feedback.

<comment><USER2> That makes a lot of sense!

> Part of maturing out of that initial stage comes from when you can > autonomously take a well defined task, break it down into steps, and execute > it.

It seems like this is the scariest part--since often whether a task is well defined feels more like an assumption. In a lot of ways, I think this is the value of social approaches--you have to answer, "how could I convince so-and- so that this is well defined?"

</comment></comment></comment><comment><USER4> I have a file called todo.txt, with the current tasks at the top, and everything else below that. It is in version control.

As I finish stuff, I delete it out of the file.

I add new stuff towards the top if I want to do it soon, towards the bottom if I want to save it for later.

For things which are just ideas, I have a second file called brainstorm.txt.

<comment><USER5> I use a todo.diff - so the text editor color codes my lines started with `+` and `-`

<comment><USER6> Similarly, I use todo.md, and have VIM highlight "[ ]", "[x]", "[>]", "[v]", and "[-]" for bullet-journal-like TODO, DONE, Deferred, Dropped, and FAILED, respectively.

<comment><USER6> (too late to edit)

Like this: [https://github.com/jodavaho/bashlog](https://github.com/jodavaho/bashlog)

</comment></comment></comment></comment><comment><USER7> I use Trello, then it gets messy, switch to Keep to start over, that gets confusing or messy, I have a txt file with my todos, that gets messy, I try a project management tool like Basecamp, doesn't do the trick, start over fresh on Trello, that gets messy.... I think you see where I'm going with this.

<comment><USER8> I also use a text file to keep a daily development note, like a blog post but keep it in the project's root just for me to see what's I've done and what I'm planning to do in the next day.

<comment><USER9> Do you add a new entry every day to the top of the file? Do you check this into git?

<comment><USER8> Almost everyday, or days when I work on the project. To the bottom of the file.

</comment></comment></comment></comment><comment><USER10> Most tools have a lot of overhead. As a solo dev, your advantage is speed, but a little friction and grist is needed sometimes.

It takes only an hour or so to restructure it for more than one person, so cross the bridge when you get there.

For to do lists I use Sublime+PlainTasks plugin. It's fast, sticks in your head. If you want something cloud, Workflowy might be good too.

Without a product manager or scrum master it's also easy to get into tunnel vision and stray. I sometimes enjoy having an extra person to bounce ideas off and tell me to keep on track. If it's a startup, get a co-founder, give them 10%-50% just to tell you listen to you. It seems a little unfair, but it's worked for me.

Another trick would be a design doc to remind you of design decisions. I'm happiest with this format: [https://random-character- generator.com/whatisthis](https://random-character-generator.com/whatisthis)

<comment><USER11> I agree, for my open source it's based on what I need and I throw code in and out quite fast. I have a mental "list" of things that bother me so I try to do these when I have a moment. If I forget something in the list, it was never important by definition.

This is mostly for projects made for fun though, I would not recommend this for a startup-like solo dev.

Edit: I also do an overview from time to time of the projects as a whole and decide if a larger feature is important.

</comment></comment><comment><USER12> I use the concept of demo days - where I demo something to myself. Some people would think of it as a sprint, but a demo enforces that it is something I can actually show. Like "I can launch the program and have it say print 'hello'". In my experience this works much better than stages or percentages. Lots of things just fall out. A demo that has bugs is not a demo for example.

I use a stack of demos, each as a 3x5 card. Low overhead, easy and quick to modify, etc.

As a solo dev it is was too easy to get lost in the process and tools, but this works well for me.

</comment><comment><USER13> As many other have suggested, I found ClubHouse [1] to be the best balance for solo dev.

I have tested and worked with many. Asana, JIRA, Trello were all tested alone and with small or medium sized teams. None were as simple to use and clean as clubhouse.

It was always hard to keep the big picture while going into details with theses software. But with Clubhouse am using Iteration to define the big picture and the planning of the upcoming weeks and it just works great.

Their support team is on Slack and reactive to feedback. The software seems really progressing well and the UX is polished and well thought. They really are building a cool product.

Note that I have no affiliation of any kind with any of theses software. It's just my personal taste and experience of the last ~ 10 years of software development and project management (am a Product Owner in a software company).

Wondering what will be the next one I'll use after Clubhouse.. time will tell!

[1] see [https://app.clubhouse.io](https://app.clubhouse.io) for more

<comment><USER14> I will second Clubhouse as a great tool. It's far better thought out than Jira and attuned to software life cycles unlike Trello.

</comment></comment><comment><USER15> I use github projects with a Research/Maybe, Todo, In Progress, Testing, and Done columns. Each item has a checklist of steps needed to complete the item. For example, I might have an item that is "Workers have an inventory" and a bunch of steps to do that "Add an inventory component, add a take item event, etc." that are markdown checkboxes.

This lets me do some 'design' via listing out all the classes/touchpoints, while still giving me the flexibility to tear stuff up, shuffle it around, and not lose state.

I'll also often keep one text file with very tactical todos, stuff I was in the middle of typing out when interrupted, so I can quickly get back into flow state.

<comment><USER16> I do pretty much the same manually with Kanbanflow (columns represent days, leftmost is "now/current", rightmost is whatever's pushed later to my next sprint). I combine this with a pomodoro color-code for "short/easy" (1 pomo), "medium" (2-3 pomo), "long/hard" (4+) and plan my day.

I took this from uncle Bob, you just give things a rating (unitless). "Oh, that's a 6, no less!", "oh that's a 2 at most". It's enough for development (I find it's only management that wants more 'reporting' and 'estimates', being solo I do that _in medias res_ , i.e. on the spot).

However you got me curious with github projects. It seems it would integrate better for programming / design. I definitely have to experiment! Any tips to boot?

</comment></comment><comment><USER17> I use an org-mode text file for simple project management. It has two sections: Todo and Release. The Todo section has the todo items; some are marked as #feature for high level functionality and as #bug for bugs. Todo's have a life cycle of TODO/WORKING/DONE/CANCELED. When a release is made, the done items are moved to the Release section. A release has two lists: Feature and Changes. The done features are moved under the Feature list and other done items are moved under the Changes list. The Todo section manages the current tasks and the Release section captures the history.

Add new feature or ideas to the end of the todo list. Add related todo's under a feature line. Add bugs as they are found. The order of the todo items is the priority. Move them around as needed. When canceling a todo, record the reason, so in case if it comes up again, you have a record of decision. That's it. It's pretty simple.

Below is a sample from one of my side projects (solo dev).

        * Todo
        ** DONE Filter out Export Panel page when doing session snapshot.
        ** DONE Add command "Optimize Tab Favicon" on the Utilities tab in Preferences.
        ** DONE #BUG cancelled dialog causes double event firings on the next dialog action.
        ** WORKING #FEATURE dark theme mode support.
        ** WORKING Add light theme, dark theme, and default theme.  Refactor CSS.
        ** TODO Apply theme to components.
        ** TODO #FEATURE session push to remote devices.
        ** TODO #FEATURE Localization.

        * Release 2.11, 04/02/2019
        ** Feature:
        - #FEATURE Package the custom Web Components with the addon distribution.
        ** Changes:
        - #BUG All the dialogs are not showing, due to the missing custom components in the distribution package.
        - #BUG Error when a pinned tab is restored with the 'discarded' flag set, for lazily loading.
        - Restore active, reader-mode, or pinned tab as fully loaded tab, no lazily loading for them.

        * Release 2.10, 03/14/2019
        ...

        * Release 2.9, 02/21/2019
        ...

</comment><comment><USER18> I use two paper notebooks per project: one for planning/architecture/schematics which is used for more long form writing.

Second notebook is for todo items (like add name validation for model Item). When I finish something I cross it out. I usually scan past two or three pages, so many things are left in void. Thats actually a good thing, if something is important I just write it again on fresh page + I occasionally go through wider history to check if something important was not left behind.

\+ I keep Notes app open all the times with note per project. Here I keep list similar to the Todo notebook but it contains things that have to be done. Once I am done with task I delete the line.

Basically paper notebooks are for development of fresh features and Notes is for bugs and fixes of production code.

</comment><comment><USER19> Fancy tools are for teams, because everyone editing todo.txt eventually gets messy. It is not like you can't use the fancy tools, but if you expect them to somehow improve your work flow, prepare to be disappointed.

The thing about working solo is that you can get away with a lot less communication and writing stuff down. Depending on your memory you probably still should put a few core ideas on paper/file. As long as you are prepared to delete as necessary, putting ideas in code right away might work.

<comment><USER20> I've been experimenting with a TODO for every branch and then merging the TODO into the main TODO when you merge to master. For example, you have a main TODO that has the general things you want to do. When you open up a new branch, you create a new TODO file named after the branch in the TODO directory. You move the TODO items that you are going to do into the new file (and add extra details). You work on that TODO and when you are finished with the branch, you move any not-DONE items into the main TODO file. This will cause occasional merge conflicts, but since you should probably inspect the priority of close items, it's not really a problem.

I've mostly done it just for myself, but have occasionally tried it with 1 or 2 other people. It seems to work reasonably well. The only real downside that I've found is that if you want to take the TODO items out of the master branch when you are working on them, it requires another commit to master, which is unfortunate. However, in doing that, your master branch has a TODO file for every branch that it in active development, so it's not really that bad...

I've not really lured anybody away from Trello, though. People like their specialised GUI ;-) Org-mode/MD just doesn't do it for a lot of people.

</comment></comment><comment><USER21> I've tried almost every tools out there but for some reason the one that makes me the most productive is just a plain old pen and a notebook. It is what keeps me in line and focused.

I don't even write much useful stuffs on it but it keeps me actively engaged on my tasks. So I just have it next to me at all times.

I don't even look at previous pages so I tend to write what I need to be doing that day.

<comment><USER22> Same for me. I feel like all these tools just get in your way and you end up spending more time writing cards and todo items than actually crossing them off the list.

</comment></comment><comment><USER23> I eventually learned (the hard way) to start getting users from day 1. Before I start coding something, I start with paper and pen and find a user.

I build (quickly, usually always hardcoded stuff) it and show to user. They like / dislike it, and I go back and I fix it.

At the same time, I get more users (usually through meetup groups and making friends). People are flaky, they stop using my app eventually so I plan to make a steady stream of friends / users.

Eventually I find someone who wants to help. We go out to get users together and share weekly what features are most requested.

Now I have 8 developers. The people who interacts with the most users have the biggest say in what to work on next, whether it be refactoring, bug fix, or feature build. We started using post-its, but now we are using gitlab issues list and monthly milestones.

I hope to continue this forever so I don't lose touch with what is good for the user. I don't care about data nor the people who create the data, I want to always interact and make friends with my users so I can always make vision driven decisions and not get manipulated by misrepresented data.

A trick I've come up with is to "fake" the initial product. One time I put a loading time of 1 day to process some data, but I'm actually doing it manually when I got home. Eventually, to save my time, I write a script to automate my work away.

</comment><comment><USER24> I'm insane, so I just create a parent task in taskwarrior: "build real estate app for client x"

Then anything that falls directly under that is a blocking task:

\- "build backend to serve api"

\- "build frontend" (this might be blocked by the one above, or not, depending on what it really does) \- repeat ad naueseum until those big tasks are broken down enough for me to visualize

Using a project might be nice to get a progress bar, but sometimes something I need to do doesn't fall exactly under this project, or might affect existing projects:

\- increase block storage for shared server

So I just use a single, parent task, and have child tasks that block it. That way I always know what to do next, and I keep going until it's all done.

<comment><USER25> This is the same process I use on a whiteboard to plan out complex projects at work with my team. It's a nice way to see what tasks can be worked on simultaneously in non-solo work too.

As a side project I'm currently working on a tool to do this planning visually.

<comment><USER24> My sole gripe with TW is the lack of a pretty GUI and a power mobile app. Both problems I can solve on my own, mind you, but still...

Plus I know it'll be a huge problem if I ever have to work with anyone else.

</comment></comment></comment><comment><USER26> Personal Kanban: [http://personalkanban.com/pk/personal- kanban-101/](http://personalkanban.com/pk/personal-kanban-101/)

Try the book.

After the book, you'll be better equipped to scale from 2 or 3 devs to 20 or 30 devs while remaining low overhead, because you'll understand the essence of iterative and collaborative development versus what's been watered down and ceremonialized into Agile/SCRUM.

<comment><USER27> Thank you! Finished the book already since reading your comment. Very simple, and encourages (and shows examples of) personalized variants, experimentation with the system etc. I like it. Gonna start today.

I've been just deleting things from TO DO lists when done.. which isn't very satisfying!

</comment></comment><comment><USER28> I use github's kanban board and like the concept of Kanban overall. Some people don't realise that Kanban is quite the opposite of Scrum.

One variation that has worked for me / peers over the years is having a "Next 5" column. i.e. something bigger than Current but smaller than the backlog.

That enables always having a practical, prioritized mid-term plan (assuming you regularly tweak the Next 5 selection).

At the same time you don't stress about a supposed deadline for forthcoming work. You just pick the next card, only when the current one is done. That's called "Flexibility in prioritization" as per asyncmanifesto.

<comment><USER29> Me too. I recently realized that you can have user level projects instead of repo level. This was a sticking point for me because sometimes a project goes across repos.

[https://github.com/USER?tab=projects](https://github.com/USER?tab=projects)

</comment></comment><comment><USER30> I use Google Docs. It's accessible from my laptop and phone and anywhere I go. It also has offline mode and auto-syncs when I reconnect to the Internet. Here's my format:

#Todos

\- todo1

\- todo2

#Dec 2019

Mon 2019/12/30

\- Done

\- Assessment

\- Next

Sun 2019/12/29

...

I also have a big picture sheet for tracking multiple tasks at a high level. Each column is a project, and each cell is a milestone/task currently being worked on for that project. They are color-coded. If yellow, they're being worked on. If red, they're blocked by others. If green, they're done.

<comment><USER31> I also use Google Docs. I think it's the easiest and fastest to keep up to date and synced across devices. I put main milestones ("version" releases) at top with core features I want to implement and then a bulleted (and sub- bulleted) list of ToDos by prioritized feature below that. At the bottom I have a dump of both future ideas and resources. Has worked well so far.

</comment></comment><comment><USER32> I use a bullet journal.

I find that I can do the product and project planning much more efficiently with a pen and paper. Something about getting my eyes off of a screen really helps me refocus my thinking. I really like that, with a bujo, you have to periodically make an intentional decision whether to retain or forget any un- completed to-do items. (I've yet to find a technological solution that doesn't make it way too easy to accumulate clutter.) I like that the limited space forces me to focus on the essentials of each item, which helps me to stick to the agile principle of delaying decisions to the last responsible moment.

I don't bother with swim lanes, columns, task states, or anything like that when I'm working solo. All of those concepts were invented to help make it easier for a project manager (or scrum master, or whoever) to keep track of and coordinate the efforts of many people on a team. Humans suck at multitasking, so, if you're solo, you shouldn't have more than one or two items in progress at a time. Meaning you shouldn't have any need for techniques that are designed to help keep track of lots of things at once.

I don't find much value in a non-paper solution because the main advantage of electronic solutions is to help with intra-team communication on a geographically distributed team. If you're an army of one, there's no intra- team communication or geographic distribution to manage in the first place.

<comment><USER33> > (I've yet to find a technological solution that doesn't make it way too easy > to accumulate clutter.)

Try NotePlan ([https://noteplan.co](https://noteplan.co))

</comment></comment><comment><USER34> I've been doing Trello.

Instead of a "Done" list, I make one with my next version number (e.g. 4.1).

Then, after I release 4.1, I move that list to a "Releases" board and replace it on the work board with 4.2.

</comment><comment><USER35> Github issues and milestones for me.

Generally I put all features, ideas, bugs, etc into small granular issues that I can ideally complete in a day or two. I'll group them into milestones representing high level goals ("implement video editor", "v1.1 release", etc) and then prioritize issues accordingly into a kanban dashboard.

I find that this method takes little extra time and lets me separate my development brain from my project management brain. I can come up with high level design and compose goals, then start hacking away later in tiny sprints without needing to think too much about how things fit together. Issue comments are also great places to record ideas when you're e.g. at a bar with friends and have a sudden breakthrough that you want to jot down.

Most importantly though it helps with motivation, since it's usually much easier to pick up my laptop knowing I'll be able to achieve something that day rather than making incremental progress towards a larger goal.

</comment><comment><USER36> There are two levels of organization. Time level (which projects when, meetings, sprints, time allocation) and project level (user stories).

For the time level stuff, I use Google Calendar. This allows me to plan development work for the various projects around any meetings that end up on my calendar.

For the project level stuff, I use JIRA in kanban format with Blocked, Backlog, In Progress, For Review, Done.

I've been doing it this way for more than a decade ...

> Works ok but I feel I can do better, like adding a progress % or something > to get a better overview of my tasks.

JIRA will give you a burn-down chart automatically, but honestly, that stuff is worthless.

One piece of advice. Do not kick back user stories unless there was a defect in the work. If you want to add something or do something differently, make a new story and mark that one as done. It kills morale to see the same stuff over and over again, makes it look like you're not making progress.

</comment><comment><USER37> Perhaps I'm too old school, but pen and paper works best for me at least for short term planning, for more general/longer term roadmap GitHub project boards do the job.

</comment><comment><USER38> I've been a fan of regular github issues and milestones and labels.

I'll typically have milestones for the next 2 or 3 releases, and then use labels for tracking bugs, features and future items and nice-to-haves. I like this because it makes it easy to keep the code linked to issues the way I'm used to with my day job.

The nice thing is it lets me wear two separate hats. Some days I don't have the mental bandwidth to code, or I'm feeling extra creative when it comes to coming up with roadmap ideas, so I'll go into the issues and just write. On other days, I just open the issues, filter by bugs or features and grab an item and get to work.

I've tried Trello and Basecamp, but having that separate from the code just made too much overhead to keep track of. Having everything under one roof makes it so I actually end up adhering to the list of tasks.

</comment><comment><USER39> I use pen and paper, it gets messy, then I pull out the paper and re-write the list on a new paper. Then I try and do the things written, but often start doing all kinds of new things that are not written, and only when I think of something that seems "cool" do I write it down to not forget.

<comment><USER40> I do this too. Having to rewrite old items every week or so once the front page is full makes me reconsider if they're worth doing at all. It's pretty effective.

Ironically I started doing it when I was working at a bank where online tools were forbidden and the programming environment sucked but it stuck with me even after.

</comment></comment><comment><USER41> I tend to use a simple txt, it is always open on my editor, and I put there the TODO, or any bug I found, markdown format. If I have to persist this information I tend to use github issues and use a PR flows, but in general a txt is more than fine, just use that. If you get fancier than that I can assure you will get dizzy on tools. I've been working like that for 6 months in a row, alone. And I have to tell you when I'm tired of backend programming I move to the frontend , doing some visual adjustments, just for fun and mental health, then I switch back to the backend and so on, also this cycles are switched by testing, design, programming, flow design etc...

</comment><comment><USER42> I use Taskwarrior ([https://taskwarrior.org/](https://taskwarrior.org/)) because it's digital, simple, customizable and open-source. Gives me just enough flexibility without complicating things. It's a shell-based tool which makes it very portable and easy to automate.

The workflow is centered around "tasks", which can be as simple as a description. You can add tags to tasks, filter by tags, set task priorities & due dates and assign tasks to a project. Much more to love, I recommend checking it out if the above description interests you.

</comment><comment><USER43> I use github issues with custom tags (bug, feature, docs, tests, etc). I am not too picky about what goes into the issue list, as long as it has a good title and description. I use a github project board to prioritize what to work on with a simple kanban setup. The backlog column is ranked with upcoming items up top and never more than 2 features "in progress" at once. This setup helps me focus on what I need to knock out without too much mental overhead, and is especially helpful when I come back to a project after a break. I also use the github milestone feature to track issues that roll up into releases. At the end of the milestone, I copy the list of completed issues more ore less verbatim into the changelog. I keep the setup as lightweight as possible, and avoid 3rd party integrations at all costs. The linking UX between the 3 features I use (issues, projects, and milestones) makes navigating the project convenient, without feeling like I am locking myself into github as a vendor. I avoid putting too much work into the kanban backlog beyond what's in progress or next up for this reason, and releases are kept small so I could recreate them in a few minutes in a text file if I moved to another platform like sourcehut. In general, I avoid getting too far away from a basic todo list. Tools like Jira or Asana have loads of features that provide little value to a developer and a lot of lock-in.

<comment><USER44> Why 2 features in parallel and not just one?

Do you have external dependencies that block your progress, or is it to be able to switch between them and not always do the same thing? Or something else entirely?

<comment><USER43> Sometimes I like to alternate between two features or bug fixes just to stay motivated with a bit of variety. It does break the kanban spirit a bit, but I avoid allowing anything to hang out too long in the "in progress" column to prevent procrastinating on a tough issue. Most of the time I only have one issue in progress at a time.

</comment></comment></comment><comment><USER45> As someone who recently started working for a startup with no computer science/coding background, this thread has been insanely helpful and relatable based on my experiences working in accounting/healthcare.

It's almost enlightening hearing similar problems across industries when it comes to task completion and execution of strategies/development ideas. I can't tell you how many times I would update our "tracking log" (a basic-ass Excel spreadsheet with project owner, general information, and date to complete task columns) to no avail. Someone would miss a deadline and tasks were constantly added without dropping off any tasks or moving them to the "complete" stage.

Trello is only as great as the work being done to execute on the assigned tasks. I really think it just comes down to getting shit done.

One technique I found very helpful is physically writing down the tasks you want to complete on a little 1x1 sticky note. This helps you stay concise with what you NEED to get done that day/week and keeps you from adding things you know you CAN'T accomplish within a respectable time period. Once you finish that task, you then cross it off. There's something uber satisfying about crossing things off with a pen.

I think the main goal is to set realistic expectations and hold yourself accountable for those tasks. Try not to overburden and add tasks to the never ending list. It just gets daunting and stifles your creativity or willingness to execute.

</comment><comment><USER46> Take a look at Clubhouse, I think it might be right in the right range for you: [https://clubhouse.io/](https://clubhouse.io/)

</comment><comment><USER47> I think the right 'process' for each person is more important than the 'tools' etc.

The tools that will suit your needs , you will learn/make/find over time of use.. The process though is the foundation imo.

I have a few habbits that I absolutely know could be improved on, optimised etc, but they make me comfortable, they are my solid automonomous actions, meaning I never need to worry about them.

Autopilot mode kicks in.

That takes time and just noticing what you don't like and removing / changing those things.

Good luck.

PS: Beer helps! o7

<comment><USER48> > I think the right 'process' for each person is more important than the > 'tools' etc.

This can't be overstated. We often get stuck into looking for "the perfect tool" for things, when the tool is rarely the most important thing. The process is king, and any tools should be chosen to support the desired process.

</comment></comment><comment><USER49> Kinda depends on how large your product / project is. I work as a (mostly) solo dev on very large projects that are typically completed by teams of 5-10 and take 6-12 months to complete (even for a those teams).

* Pivotal Tracker is IMO the best agile PM system.

* I break each project into Epics, then down into discrete Stories, basic agile stuff.

* I only score stories at 1, 2, 3, 5, 8, 13. Anything larger MUST be broken down.

* Any story scored 8 really should be broken down into smaller pieces. Any story scored 13 MUST be broken down.

* I use Harvest to track time against individual stories, and require that any subcontracted developer do the same. This allows me to determine for any given dev, including myself, how much actual time a given point weighting equates to.

It's a lot of work to do this at the outset of a big project and feels very waterfallish. And it's tiring to think so deeply into implementation details. But it's very much worth the effort.

My personal pattern is to whittle the project down in multiple passes. So Pass #1 is just breaking things into Epics. Pass #2 is breaking the Epics into 8 or 13 point stories. Pass #3 is breaking those 8/13 pointers into 1/2/3/5 stories.

I absolutely do not open an IDE until this process is done. It's so tempting to just start writing code. Avoid that temptation. :)

<comment><USER50> > I absolutely do not open an IDE until this process is done

How do you deal with changing requirements? Or when your understanding of the problem changes midway into the project? I find that one or the other happens frequently. It's nobody's fault (most of the time), just the result of the reality that customers don't always know what they want and are frequently unable to accurately communicate what they want.

<comment><USER49> Oh that happens all the time, sure. I'm referencing what I do at the _start_ of a project.

</comment></comment></comment><comment><USER51> Emacs Org Mode is nice for note taking planning and todos, the calendar timestamping features is nice to recognize time spent in various tasks and keep accountable

</comment><comment> c-smile One of reasons I did my Sciter Notes ([https://notes.sciter.com](https://notes.sciter.com)) is to track ideas and progress (see checkmark list button). Idea definition frequently require hyperlinks, images, etc. so todo.txt is not enough in case of UI related stuff.

Also to track customers, their licenses and services.

Sciter Notes is storing data strictly on local drive and so the data is not shared with third parties.

</comment><comment><USER52> I just have a text based notes file for each project that informally keeps track of everything in a pretty unorganized way.

I'm a big believer of keeping old text around too, so I don't delete things after I finish them because that added context for later usually helps a lot.

I use this to actively juggle 5-6 freelance gigs and a bunch of personal projects. I find it really easy to jump into any of those projects and get up to speed quickly.

In general I keep "busy work" to a minimum. Often times I would rather get into the code and even add pseudo code comments or TODOs instead of kanban boards and other things.

For project planning (pre-single line of code) I just brain dump stuff into a text file and go from there. I once live recorded myself doing this for a project a while back at [https://nickjanetakis.com/blog/live-demo-of-planning- a-real-...](https://nickjanetakis.com/blog/live-demo-of-planning-a-real-world- web-application-from-scratch).

I also like that my notes file is local instead of an external service. It lets me jump between that and my code very quickly since I can use my code editor to interact with it.

</comment><comment><USER53> My process is similar. I use Trello with four lists: Backlog (further out feature ideas, ambitious or less important refactors, edge case bugs), To Do (basically an extension of Backlog for things I plan to work on imminently), In Progress and Done. I also have labels: Feature, Bug, Refactor (user- impacting things like improving performance), Developer (non-user-impacting things like importing infrastructure into Terraform) and Marketing.

One thing that has helped me immensely is using checklists on Trello cards. Unless a task is very simple, I generally make two checklists: one for implementation and one for QA. The act of making an exhaustive QA checklist in particular has helped me figure out edge cases that affect feature development, and going through each and every scenario outlined before releasing has caught a ton of bugs. As a bonus, I get a progress meter on each task.

It's enough structure that I have a good handle on everything, but loose enough that I don't spend much time appeasing my product management process. I'm only coordinating with myself here, so I think adding more tools or processes would just slow me down.

</comment><comment><USER54> I use dynalist.io (similar to Workflowy but more actively being developed) - I've found that the lists-within-lists patterns maps well to the way I think - if there's more than one layer of subtasks, Trello tends to not map well. I usually keep a 'Today' list that I fill every morning and work through.

I'm planning to try out notion.so though - I have a feeling it might help with the friction that I currently feel when duplicating items from my long term 'how should the product work' structure and the 'currently working on' structure.

My most important insight as a solo dev is that you need to manage your own motivation, and that what is required to do so varies. I've found that I easily procrastinate in the beginning of a new project, when nothing is defined yet and it's mostly research, trying to figure out what is even possible and what is desirable. In later stages it's easy to motivate myself, since I get that dopamine kick every time I tick something off from the todo- list. But in the beginning, there are no small, well-defined tasks, just research and analysis - to my brain, that feels like wandering the desert with no end in sight. So I motivate myself by doing pomodoro technique instead. That way every time I finish a pomodoro (25 mins of focused work). I get that little dopamine kick from that instead. Long story short, it's best to track and reward progress, but when that's hard or impossible to do, track and reward effort instead. I use this app on my computer to keep track, but I'm sure there are other good ones: [https://apps.apple.com/gb/app/be-focused-pro- focus-timer/id9...](https://apps.apple.com/gb/app/be-focused-pro-focus- timer/id953426154)

</comment><comment><USER55> I use Todoist to log work for my company ChipBot.

I have a groups like feature requests and backlog for catch-all tasks. Then for deadlines I use "Mid January" or "End of January" and move tasks into them, based on a rough hour estimate. Story points doesn't matter because I'm not quantifying complexity across a team members. It's just me working on it.

I work on the tasks that have the highest priority, build locally, test them in a QA instance, and then ship them to prod. I usually run smoke tests in prod just to make sure I don't break something.

I used to use GitHub tickets and JIRA, but over time I needed organization that didn't cause a lot of busy work. For myself, Todoist (paid plan) works.

If I need to add members in the future, I'll go back to using GitHub (kanban, labels, milestones). Most likely my marketing team will need a Kanban before I add another developer.

Other notes:

Use tools that get objectives done and don't create micro tasks.

Finally, create tasks during off time like during lunch, while working out, or on a walk break. I generally plan 2-3 days in advance on the exact work I need to get done. Don't over work yourself.

</comment><comment><USER56> 1\. Come up with a feature.

2\. Code it.

3\. Test it.

4\. Release it.

Occasionally: Think if there's any process/code problem you keep running into, and spend some time fixing that.

Don't overthink it. Most of the process ideas that exist out there exist to facilitate communication, which is completely irrelevant if you're the only one.

Also, don't create a process for people who don't exist yet. They may never exist, and if they ever do exist, your process will need to accommodate their needs. Having a process already in place creates a "this is how we do things" that creates opposition to accommodating the needs of new members, and puts them in the position of having to change a process they never agreed to and had no part in creating.

Remember, _agile isn 't a process, it's a set of principles_[1]. "Individuals and interactions over processes and tools" means that you find the individuals _first_ , and collaboratively build a process that works for everyone involved.

[1] [https://agilemanifesto.org/](https://agilemanifesto.org/)

</comment><comment><USER57> It depends on the situation but like some of the commenters here, I use two whiteboards for rapidly putting things together. I have a larger one for drawing out the architecture—relationships, expected behaviors, purpose statements, that sort of thing.

Then, I've got a smaller one that lets me design a rough skeleton for UI (when applicable). If I can wrap my head around how I can expect a user to touch various parts of the project, I can better plan for what data requirements I anticipate needing.

But when it comes down to development, it generally boils down to avid use of GitHub. I have an unhealthy obsession with checkboxes on GitHub issues and pull requests. I used to compile todo.txt files like others, but found that they fell out of date or that I never had any reliable means of tracking what I had previously worked on. If you delete the bullet points, it's hard to find when or why.

So I split features into PRs. One, two, or three thousand lines of changes on average for a small feature here or there. When I need to clean up bugs, I've gotten a bit lazy and will just sneak them into commits on master. Squash and merge lets me point back to the PR that I created and I'll throw a description of all my work into the body of the PR.

GitHub issues lets you know what work needs to be done and when the PR is filed, the issue gets closed (i.e. you put a small "This closes #N" in the body and when the PR is merged, GH takes care of the rest).

It might not be an efficient system but I've tried things like Trello or project boards in the past and I couldn't bring myself to shuffling a deck of a hundred cards every time I touched one small thing. As soon as you increase the distance between your code and your project board, it feels like going through that many more steps just to update everything. It works for some but everyone is different.

</comment><comment><USER11> A major problem I've seen with Engineers following a TODO-like tasks is that you get lost in the small things and lose focus of the bigger picture.

While they are useful, I also try not to forget things that are vastly outside of the list like regular user testing, talking about it with other fellow engineers (dev testing?), try to make a workable MVP and sell it early, etc.

<comment><USER58> Need an overarching vision. Absolutement. That's why I like to simply keep track of what I am doing or want to do in a calendar-like way. I never delete things from my logue of completed tasks, I just keep adding new dates and new ideas/finished tasks/want-to-dos at the top. It works well when you have an overarching goal.

</comment></comment><comment><USER59> Whiteboard - For me, tangible writing helps with creativity and thought processing and a whiteboard saves on paper if it's not going to be a permanent thing (and even if it is, a simple photo of the board for retention).

Google Keep for quick notes on the go with a permanent pinned tabbed in my browser for quick access

Trello for day to day development management but not as detailed as I would in my work, simply as I don't need it to be. Speed is an advantage for solo projects and small teams so adding unneccessary processes reduces that advantage IME.

Specialised comments within Visual Studio to allow me to write comments and easily find them again without disrupting my flow (I believe IntelliJ and other IDE's may have analogous features) [https://keyboardp.com/post/40190774577/using-task-list- token...](https://keyboardp.com/post/40190774577/using-task-list-tokens-in- visual-studio-to-improve)

</comment><comment> kalium-xyz You can use email as a TODO stack. You take the top item of your inbox and react to it. You react by replying to it, archiving it, or by doing the task(s) described in it. To add a new item simply email it to yourself. Archived items are done. Inbox is the list of items you working trough. Send items is the things you are waiting for.

<comment><USER60> Perfect for those of us running our own email server :)

</comment></comment><comment><USER61> Over the years I have compiled a log of project metadata. Nowadays I use it to forecast and plan each project task. The key part is having the task to time forecast for your overall environment (people, company culture, country, …) .

Every project starts with a drilldown of requirements to tasks (just name and description), the more detailed the better. For each task I add a subjective complexity. The mapping of complexity to actual time is based on previous projects metadata.

I try to add a task for each time-consuming effort, documentation, HW procurement, HW shipping, cabling, development, validation, acceptance tests, baby-sitting, billing.

The metadata is a living document, it adds more rows as the project progress.

For tracking the metadata, I use a Google Sheet for each project as a tracking project management. TODO file in steroids. There are two levels, one for the task and another for steps in the tasks.

Each of the rows have more or less following information.

       * id, name and description

       * status

       * owner

       * area

       * initial perceived complexity.

       * final perceived complexity

       * external perceived pressure

       * dependencies

       * total involved people

       * initial estimated time

       * dev starting time

       * ending dev time

       * real development time

       * testing starting time

       * test ending time

The tracking is updated daily (last action before going home) or when a new task appears. It doesn't take much time.

Once the initial per task forecast is done, I have also try to put the high level tasks and its dependencies in a classic Gantt waterfall (using projectlibre). The Gantt gives an initial idea of the time, but it has never been fully accurate, because as project evolves, there are always new and unexpected tasks.

Note that the pressure column in the list above, is one of the principal inputs to forecast, due to Parkinson's law.

</comment><comment><USER62> The main advantage of tools like this are that you can use them to communicate. When I don't have the need to do that, I don't use them. I try to use tools that will remember this sort of thing on their own.

I keep notes on ideas in a personal wiki (AwkiAwki), and I open up the recent changes page to remember what I was taking notes about. For anything past the planning or brainstorming stages, I just use `ls -t|sed 10q` on my directory full of editor session dumps. I always keep a scratch/memo buffer open in acme so there will be some brief notes, an outline of the behavior I planned to implement, or (more often) I can gather what was going on from which files were open and where the cursor is in those files. For non-code projects, there will at least be some text, so there will be a session dump.

</comment><comment><USER63> Personally I use the Notes app available on the MacOS / iOS platforms. I organize it with a folder per project. I love it because it is simple, supports checkboxes, formatting, freeform drawings via iPad+Pencil, syncs across all my devices, allows password locking certain notes (though I don't really use this - I use 1Password to hold sensitive info via its Secure Notes feature) and is even available via the iCloud website if needed.

Within that folder I keep one note that acts as the ToDo list / Work Log that contains all the work items plus dates of completion. The rest of the notes are ad hoc and usually contain stuff like "Meeting notes - <subject> \- <date>", "Follow ups", "Questions/Clarifications for later", and so on.

</comment><comment><USER64> As a solo game dev, I've tried a number of various project management tools that I use in my DevOps day job... from Trello to Planner to Jira to Azure DevOps. I like Azure DevOps work items the best, but the reality is that for a solo developer, I've found all of these tools create far too much overhead (so that I spend more time managing the project rather than making actual progress on it).

So for practical use... I tend to write my ToDo list on a whiteboard near my workstation.

When I complete items from the whiteboard, I move them into an Excel spreadsheet where I can add greater detail about the resolution/solution.

When I'm ready to release a version update, I take the notes scribbled into that Excel sheet and turn them into properly formatted update notes.

</comment><comment><USER65> I use a Google sheet + a todo.txt.

In the Google sheet I log the requests. Depending of the project I add columns with a 1-10 value (For exemple: "value for user", "cost reduction", "traffic increase", etc). I then sort all the requests by a column having a formula where each dimension has a weight related to its importance (= 5xd8 + 2xe8 + 10xf8). That way, I know which request are the most important without "thinking too much".

In the todo.txt, I break down the current tasks in smaller tasks. That way: It helps me understand tasks, I can track what I still have to do, it "structures" my work and it helps me not to forget "little important details" that must be done.

</comment><comment><USER66> Instead of Trello you can use Github's Projects. It has kanban boards like Trello and it can create progress bars based off of each of your tasks. They also support various automation features based off actions with your branches to move cards around.

<comment><USER67> I use Restyaboard, an alternative to Trello, that has the same Kanban features, as well as other views such as a to-do list and mind map. I love the visual aspect of the boards and being able to make lists for each topic is nice.

</comment></comment><comment><USER68> I was shaping such system myself and after some time I understood that global kanban boards are enough, but what is more important is how do I focus (and return to the focused state) during the work.

To focus and return to the focus better, I'm using a mix of:

\- project microtasking with kanban board (automatically handled using scripts/app) and TODO/FIXME comments

\- lazygit utility

\- global todo kanban board (think Trello, GitHub Projects etc.)

I was looking for a system that will maximize my productivity during few hours per day when I work for myself. I discussed this system before on HN: [https://news.ycombinator.com/item?id=20780939](https://news.ycombinator.com/item?id=20780939)

</comment><comment><USER69> I organize todos in the note-taking tool I'm building, [http://remnote.io/](http://remnote.io/).

I have a main "unsorted todos" inbox that I can quickly add to from anywhere (I just hit CTRL + ALT + E). I then go through this list and organize it by moving the ideas to specific features that I'm building / designing. My high- level areas of focus are already set up, so this organization process is pretty fast.

I like keeping my todo list with the rest of my notes, because I can write long brainstorming docs paired with my todos. Additionally, I can make linked references to the todos from elsewhere in my notes.

</comment><comment><USER70> Also using Trello and especially their checklists. Each 'iteration' has a checklist and as I'm done I check it off. I guess they are like issues in an issue tracker with less fuss.

Since I have all the 'iteration' there I also have a 'Future' iteration. As I'm approaching some self-imposed deadline I remove/add tasks from the current iteration to Future.

If I didn't do anything in quite some time I have the tasks right there waiting for me and I can pick one.

This mode of work for solo projects is quite good imho. Used it for openbeans.org / coolbeans.xyz, for mastodon.ro and for another project which doesn't have a website anymore (YaMeter).

</comment><comment><USER71> There's already extensive commentary on the organizing side of planning, but for my personal projects, much of my planning is thinking through the problem and recording my thoughts.

I've found Inkdrop[1] is quite good for that; there are a ton of them out there, but it has nice tagging and the ability to set a Status so you can have a set of notes "in progress."

I've tried a few mind-mapping tools, and can't recommend them, unfortunately. And none of these tools really talk to each other, which is disappointing.

[1]: [https://inkdrop.app/](https://inkdrop.app/)

</comment><comment><USER72> The most important tools I've found is simply setting milestones and deadlines. The software almost never mattered - the mentality of setting myself accountable to deadlines was so much more important. When fleshing out smaller tasks for milestones, I've used Evernote, Clear, Notion, Trello, Google Docs, etc. All of those are great, but I never really cared about the % progress - only that I was going to hit the deadline and working as hard as possible to reach it. The tools end up being a way for me to not forget little things I decide to shaft in order to reach a ship date.

</comment><comment><USER73> Todoist. I organize my projects in separate projects or sections in projects, depending if they have big or smaller scope.

I also import my Github repo's PRs, so I can plan everything in a single place.

Every week I plan the next one and I review my planned day while I commute.

I split tasks in several subtasks and I keep track of my progress looking at how short is the subtasks list per each task.

I also usually take few minutes a day to refine tasks to see if I missed some subtask or I can improve the description.

My workflow is heavily inspired in Agile/Kanban. My progress is measured overall with Todoist Karma.

This could work for more devs, as you can share and assign tasks.

</comment><comment><USER74> With KeyDB I keep my todo list in my head. Once in a while I'll go scour github issues or feature requests. So far no other tools have been necessary.

I think when things are small adding too much tooling or process is counterproductive.

</comment><comment><USER41> I tend to use a simple txt, it is always open on my editor, and I put there the TODO, or any bug I found. If I have to persist this information I tend to use github issues and use a PR flows, but in general a txt is more than fine. I've been working like that for 6 months in a row, alone. And I have to tell you when I'm tired of backend programming I move to the frontend , doing some visual adjustments, just for fun and mental health, then I switch back to the backend and so on, also this cycles are switched by testing, design, programming, flow design etc...

</comment><comment><USER75> After Jira (on demand), Asana, GoPlan App (which was quite good a long time), Trello, OTRS, RedMine and several others, i landed now, hopefully finally(?), at [https://www.clubhouse.io](https://www.clubhouse.io)

I like Jira at work if its self hosted, but on demand its that damn slow, its more or less unusable (every page load 10-20 sec. etc.).

Clubhouse is especially good since its free for very small teams while not limiting the number of projects/workspaces. And its mainly an SPA, so it feels really quick & responsive.

</comment><comment><USER76> I just used (and still use) org-mode to track todos & projects, as well as keep time that was spent on each task.

I tried not to over complicate my task keeping, because I've always been more worried about getting the tasks done, than trying to track progress.

Anything that was in planning/needs more info state got a WAIT instead of TODO, with a note on what was needed. And I'd review my list every morning before deciding on what I needed to work on, or if I needed to start pushing for information on other tasks.

I still do all this btw, I'm just not solo anymore.

</comment><comment><USER77> With trello, within a single card you can click "add checklist" on the right- hand side. Then add all your tasks, and check them off one by one - it shows you a progress bar on the main board.

I have a single TODO list of cards and i use the checklist within a TODO if its a large task that needs to be broken down.

I also arrange all of my links to libraries i've found online by dragging them directly onto trello or use the bookmarklet. I have about 30 boards on different topics, some with ideas, some with links all subdivided horizontally by topic.

</comment><comment><USER78> I started using plain to do lists in org-mode, then tried using GTD (Getting Things Done), but ultimately ended up building a webapp which combines elements of both and which I can access from all my devices:

[https://soliloquy.cc/manana/](https://soliloquy.cc/manana/)

It's pretty basic, but it's the right balance for me. Feel free to try it out.

P.S. I also built it because I wanted to learn ClojureScript, and I can say it's been a very positive experience.

</comment><comment><USER79> I write down all my ideas in a Trello board, and make sure that they're either easily actionable (can be done in a couple of days at worst) or tag them to split them up later.

My columns are Todo, In progress, Done and Backlog. Anything that's not a priority right now goes to the backlog. Every once in a while my Todo column gets empty, so I make a release and take stuff from my backlog.

Any time I have an idea, I instantly write it down and stop thinking about it. This lets me focus on my task at hand.

</comment><comment><USER80> I really like to brainstorm by putting sticky notes on a wall (my process [https://www.pluralsight.com/courses/agile-requirements- proce...](https://www.pluralsight.com/courses/agile-requirements-process-idea- to-minimum-viable-product)), but [https://app.storiesonboard.com/](https://app.storiesonboard.com/) is where I manage it after that.

</comment><comment><USER81> I've used PivotalTracker in the past, but it's basically what you do with Trello. IMO, if you need to track progress %, your tasks aren't broken down enough.

My process looks like this:

* Ideation Box - informal idea description

* Icebox - Long term value, that a may or may never get to

* Backlog - Short to mid term items that I want to build

* Needs Design - when I've commit to do something, but it needs a mockup

* Ready for Development

* In Progress

* Done

* Staging

* Production

Depending on the project and my whims when I start, I might keep that all in one board or split it into two section (just after backlog).

</comment><comment><USER82> I like to use a notebook for higher level thinking and Post-It notes for daily to-do lists that I cross off. I then stack them and occasionally throw them out. It's a great motivator to get that dopamine when crossing things off my list. Items I didn't get to are either carried over to the next day or broken down into smaller tasks. I try to either prepare the list for the next day the evening before or first thing in the morning.

</comment><comment><USER83> Everything starts to sprawl into tree-like hierarchy. I think mindmaps are messy but if you can branch them by file it works fine. Freeplane with nodes that link to other files are best, then from there you can migrate _some_ of that to kanban boards, which are more rigid and ordered. As a side note, that is also the best solution to multiple tabs, if you've ever had a pinned set in chrome. Best just to make them freeplane links.

</comment><comment><USER84> I use todoist, with projects per major component to keep things organized, to capture ideas for feature development. Todoist supports group collaboration and has commenting per item.

I use GitHub/Gitlab's issue tracking for bugs. It's nice to have a stable URL to reference in code to help prevent the same bug from recurring.

I keep a Google doc as a diary with daily entries to track what I got done each day, and what I want to get done tomorrow.

</comment><comment><USER85> I'm using [https://linear.app](https://linear.app). It plans "cycles" for you based on how much you accomplish.

<comment><USER86> What's the secret to get past the Typeform and actually try this? Or should I seek out an invite link from a peer

</comment></comment><comment><USER87> Get yourself a large, high quality whiteboard. Working with it is great for visualizing things and it never gets too messy because you're ultimately space limited. Every now and then you go through the upkeep - this way it doesn't ever go stale. And it's always right in front of you. No files to open.

I use a combination of the white board + Keep for more detailed stuff + per project TODO under version control.

</comment><comment><USER8> I use a todo list, sometimes paper, sometimes orgmode [1] or taskbook, or some web version [2]. But I find it really distracting to use a kanban board for personal stuff, maybe because I don't have so many stuff going on at the same time.

[1]: [https://orgmode.org](https://orgmode.org)

[2]: [https://pomoday.app](https://pomoday.app)

</comment><comment><USER88> ZenHub has a free trial

[https://www.zenhub.com/](https://www.zenhub.com/)

GitHub w/ Slack is enough for me

Best of Luck ;)

</comment><comment><USER89> I use Gitlab issue boards (they're much like the github kanban boards, but for gitlab users) to track minor tech features (on a commit level) for each of my project that can be measured with code.

For everything else (like planning db models, endpoints, roadmaps, etc) I use Notion (switched from evernote) and I love it. The templates really help.

</comment><comment><USER90> I use kanbanflow because 1 it's free 2. it works from mobile so I can note things down on the move ([https://kanbanflow.com/mobile- app](https://kanbanflow.com/mobile-app)) 3. It's simple and a slight step above the todo.txt approach (my previous workflow)

</comment><comment><USER48> I use Bugzilla to track both bugs and other wrok-to-be-done. When I close an issue in BZ, I also add a reference to which version control check-in addressed it.

Using Bugzilla as a general issue tracker makes it easier to prioritize both bug fixing and feature changes, as well as keeping a database of what work I've done, and when.

</comment><comment><USER91> I use the principles outlined in Shape Up ([https://basecamp.com/shapeup](https://basecamp.com/shapeup)) and organize my project in Minimal ([https://minimal.app](https://minimal.app)).

The key is combining simplicity and focus.

</comment><comment><USER92> Solo dev with an intermediate experience here!

I create a GitHub project (now that private repos and projects are free) with more or less the same type of boards like yours. With that triaged, I reference each card as an issue to my repo and work on milestones -- which shows the progress % :).

I used Asana before this, but I like GitHub now.

</comment><comment><USER93> Loving Clubhouse. The cards in your kanban board can move columns automatically if you sync with your GitHub org – so for example, a card will automatically move to the completed column when you merge to master. Clubhouse gives you complete control of the granularity of the webhooks which is really nice.

</comment><comment><USER94> I have make and CMake templates for C and MSVC C++ projects, respectively, and I create a Sublime Text template with a todo.txt for each project. I tend to only use VS for debugging, as it's easier to link SDL, Lua and other libraries through a CMake build than the Visual Studio UI.

</comment><comment><USER95> I used to use XMind, which is some mindmapping software. But it got a bit unwieldily.

Nowadays a todo.txt tends to suffice.

</comment><comment><USER96> I use "Note" for Android. I have a list for ideas as well as one per project. I don't really need anything more than that. I'm not a fan of Agile and don't think a framework is required for a team that small. Focus on outcomes and not process.

</comment><comment><USER97> I use Trello for both personal and work-related tasks. I have lists like <Year>,<Month> <Week> <Day Wise> [DOING] [DONE]. I also extensively use label feature and label tasks like High, Boring, Creative, etc, etc. I found Trello quite useful.

</comment><comment><USER98> Oddly enough, I still use pen and paper most of the time for smaller/solo projects. I've even written kanban boards and todo apps in the past, and there is a plethora of free ones available, I still prefer paper though.

</comment><comment><USER99> I have a Trello board for each project. On each board, there are five lists - Backlog, Bugs, Staging, Completed and Won't Do.

Everything starts on the Backlog (or Bugs) list and migrates to either Completed or Won't Fix over time.

</comment><comment><USER100> I put my projects (especially private ones) in GitLab, so I use their project management features. I like them a lot! Better than any other project planning tool I've used at any job (JIRA and GitHub and ZenHub)

</comment><comment><USER101> For 1 person, you can keep most of it in very short form. Currently I use github projects for a prioritised list of items to do, a new board per release and an ongoing Evernote file for notes & ideas.

</comment><comment><USER102> I use Clubhouse and follow a modified kanban process. It helps me keep on top of dependencies, blocked work, and whether or not I'm overloading myself in a given week/month/whatever.

<comment><USER103> I've been using Clubhouse for a new solo project as well. I love it. It's so much faster than Jira. It's refreshing using something that loads so fast and has a UI that is nice to look at.

<comment><USER102> I migrated from Trello to Clubhouse because I really needed support for blockers and dependencies, but Trello doesn't have a good way to do that without paying for certain integrations.

I still use Trello for my non-project work, though.

</comment></comment></comment><comment><USER104> Github issues and projects for each project with granular development tasks and then a trello board as an overview of all projects, meetings, calls and invoices I need to send.

</comment><comment><USER105> Google docs outline; a glorified design doc and todo list.

Project management isn't project execution. It's ok to focus on doing the thing and not your notes to self about doing the thing.

</comment><comment><USER106> I keep a TODO list in Google Keep, and I am forever shuffling entries around as priorities change.

For some projects, the issues on github also suffice to keep track of things to do.

</comment><comment><USER107> To me its moo.do (outliner) + having a sense of success. Both by addig new features and also from "testers" (friends, family) and from real users.

</comment><comment><USER108> Gitlab issues + milestone for project management, Gitlab wikis for knowledge management.

All of that on the free plan. Gitlab is really THE tool to rule them all!

</comment><comment><USER109> Gitlab in a VM for each project, Jenkins along-side too if possible, make it build every day and/or whenever a branch commit happens...

</comment><comment><USER110> You might like a product roadmapping tool like aha

</comment><comment><USER111> I write a formal specification document, as in I do classic system engineering. Even for strictly private projects at home.

</comment><comment><USER112> Trello and notebook lists, but am looking at Clubhouse. Also hoping to get a Linear app invite, since it looks pretty good.

</comment><comment> fleur-de-lotus TODO comments at the top of the file. When tasks is completed, chnage it to DONE and move it to the bottom/

</comment><comment><USER113> I used to use onenote sometimes with the todo checkbox feature. Now I mostly use Asana with tasks and subtasks

</comment><comment><USER114> I use Github gists. Comes along with markdown and revisions and feels good enough for tasks and notes.

</comment><comment><USER115> I don't, and it never ends well.

</comment><comment><USER116> I recommend taskwarrior. It's a cli todo app that can immensely help solo projects.

</comment><comment><USER117> I use Trello for the big picture, and paper and pen for more specific daily todo's.

</comment><comment><USER118> I use evernote to list down tasks in in bullet list and strike it on completion.

</comment><comment><USER119> Surprised not to see ClickUp here. I use it to manage my personal life as well

</comment><comment><USER120> I don't. I just pick the thing that is the most painful at this time.

</comment><comment><USER107> I'm wondering if there is a graph based note taking tool out there?

</comment><comment><USER121> I use jira with bitbucket. I give my clients access

</comment><comment><USER122> When it's just me, I use Remember The Milk.

</comment><comment><USER123> I use a TODO file.

</comment><comment><USER124> I find GitHub "Projects" ([https://help.github.com/en/github/managing-your- work-on-gith...](https://help.github.com/en/github/managing-your-work-on- github/about-project-boards)) is the most flexible. It is basically boards of columns. Each card can be an issue, or a piece of markdown text. You can use the markdown as a note or as a list of tasks and subtasks.

I find GitHub project boards more fun to use than Trello boards, because you can just type and let your ideas flow.

Within GitHub project boards, you can also add cards from issues, or you can convert your markdown text cards to issues.

</comment><comment><USER125> Evernote to record to do for the coming week. Airtable to record issues with priorities. Notepad++ to plan simple algo.

As a solo founder, thinking too much about optimization will just make things complicated.</comment>


A New Site That Discover And Collaborate Over News - <AUTHOR> http://www.wikio.com/webinfo?id=14930515 <comment><USER2> Why just a screenshot instead of a link to the site?</comment>


First Impressions of the Rust Programming Language - <AUTHOR> http://jakob.space/blog/post/First+Impressions+of+the+Rust+Programming+Language <comment><USER2> Not too helpful. Just comments from a new programmer.

I'd like to hear something like "This is how our team used Rust to do (really hard thing involving heavy concurrency and lots of state)". From someone _not_ involved with the development of Rust.

I was recently looking at a large, non web related C++ program which needs to be made multi-thread to increase capacity. I realized that if it was in Rust, it would be much easier to break out functionality into another thread. You need to classify data as immutable, locked, or unshared to make the program multi-thread. Rust has language support for that. C++ does not.

<comment> nevi-me It might not qualify as "really hard thing involving heavy concurrency and lots of state", but I'm nearly done writing a service that interacts with [http://tile38.com](http://tile38.com). I initially wrote it in Kotlin, and 2 weeks ago I ported it to Rust.

I'm still learning the language, so I haven't touched the "fearless concurrency" stuff, but so far it's looking __very __good.

~30% CPU time, 1-5% RAM use at peak; compared to the JVM.

I plan on writing about it, and open-sourcing the code (both Kotlin and Rust repos). Chasing a hectic work deadline at the moment.

</comment></comment><comment><USER3> As I wrote to the author on Lobsters:

Glad you liked TRPL! I agree that some of the examples can be too abstract at times, it's tough. Totally open issues if you want to talk about it; I'm open to improving things, but I'm also pretty particular about the book.

<comment><USER4> I'm really looking forward to getting the hard copy!

<comment><USER3> Me too! It's being printed right now... so close!

</comment></comment></comment><comment><USER5> _> Compile-time memory management requires designing your programs in a way you might not be used to, but it definitely beats manual memory management, or letting a runtime take care of garbage collection._

What about Automatic Reference Counting a la Swift / Objective-C?

Seems like a nice blend: compiler assisted, much less runtime overhead than traditional garbage collection, simple programming model.

<comment><USER6> Rust supports reference counting for places where you need it. There is both the RC and ARC datatypes.

<comment><USER3> And to be clear, Swift's ARC and Rust's Arc are different; automatic vs atomic. Swift's ARC is automatic usage of Rust's Arc type, if that makes any sense.

</comment></comment></comment><comment><USER7> "Also, I've been fairly critical of Rust in the past because that view was in- line with the opinions of my friends, but now that I've decided to go out of my way to learn a new programming language, I might as well use this as an opportunity to see if my criticisms were unfounded."

While this is an honest comment, why and how can you be critical of a language you don't know. Skeptical sure, but critical?

</comment><comment><USER8> Is it me, or does the Rust compiler produce terribly unoptimized code? Just compare it to the equivalent C++ code: [https://godbolt.org/g/Jdfkm6](https://godbolt.org/g/Jdfkm6). Both Clang and GCC produce really lean binary output.

<comment><USER3> Sometimes. It just depends. Some possibilities:

1\. The parent didn't say if they compiled with optimizations. I bet they did, as the code would probably look even worse without, but who knows.

2\. This isn't apples to oranges, as you're not doing formatting here, right?

3\. The formatting code makes various trade offs; it's not optimized for speed, more for size, in my understanding.

4\. Codegen bugs do happen. Maybe this is a degenerate case.

In general, if the code is significantly worse, then it's a bug.

</comment></comment><comment><USER9> first thing that jumps (sic) is that comparing puts to formatted print is not worth of a gentleman.

<comment><USER10> How would you write it, out of curiosity?

<comment><USER11> There's an example of using stdout.write at the top of this page: [https://doc.rust-lang.org/std/io/fn.stdout.html](https://doc.rust- lang.org/std/io/fn.stdout.html)

        use std::io::{self, Write};

        fn main() -> io::Result<()> {
            io::stdout().write(b"hello world")?;

            Ok(())
        }

<comment><USER3> I should improve this example, in its current form you could drop the ? and the Ok stuff...

</comment></comment></comment></comment><comment><USER12> > if let is a syntax construct that I don't think any other language has

AFAIK (not too familiar with rust or c++), you can do something like this:

        if (Maybe may = whatever; may.issome)

<comment><USER13> `if let Some(x) = y { … }` is equivalent in Rust to `match y { Some(x) => { … }, None => () }`: pattern bindings are available. Thus it is quite different from `if y.is_some() { … }`.

<comment><USER12> Is it? It does something with y if it is something, otherwise it does nothing...

<comment><USER13> To make clearer what I meant by pattern _bindings_ being available:

      if let Some(x) = y {
          println!("y has a value, {}", x);
      }

Whereas with a method, the contents of the variant are not bound:

      if y.is_some() {
          println!("y has a value, {}", /* uh… */);
      }

In Rust, pattern matching is the only to get at the contents of an enum. Methods like is_some() are just this:

      pub fn is_some(&self) -> bool {
          match *self {
              Some(_) => true,
              None => false,
          }
      }

</comment></comment></comment></comment><comment><USER14> man 3 strdup. Why is this upvoted? If you are a new programmer, don't read this nonsense.

<comment><USER15> It's true that on platforms where strdup is supported, the C example could be written more succinctly with strdup. But strdup isn't part of the ANSI/ISO standard, at least according to the man page on Ubuntu 16.04. And even when using strdup, you can't get away from manual memory management; you still have to call free (or strfree) afterward.

Furthermore, the field of programming is so vast that it's unreasonable to expect someone to know every nuance of a given language, especially if it's one that they don't use heavily.

So I don't think there's any good reason to dismiss the whole article as nonsense.</comment></comment>


The "No Assholes" rule for software developers - <AUTHOR> http://www.alleyinteractive.com/blog/no-asshole-rule-software-developers/ <comment><USER2> I never criticise code unless I know the circumstances it was written under _and_ I can be constructive about it.

I've written some truly horrible code over the years, at the end of a 80 hour week to get something up where marketing decided to book a launch event and there are two paths, the right one which will take two days and you have one or the hack which will do through launch and cause you pain later...yeah I've picked the second option.

There is no such thing as perfect code since it's written by humans and we are all imperfect.

</comment><comment><USER3> I think this raises good questions about developer attitudes. It is possible that I might fail this test if thrown into one of the article's scenarios. I will think on it.

However, the article's scenarios also clearly illustrate that there is no "No Assholes" expectations for management.</comment>


Master the 5 Elements of Customer Service - <AUTHOR> https://www.freshworks.com/live-chat-software/5-elements-of-good-customer-service-blog/ <comment><USER2> Marketing text and not the good one. Worthless, sorry.</comment>


Possibly the easiest way to register to vote - <AUTHOR> https://www.gottaregister.com/

<comment><USER2> This seems like an interesting idea, and the cert is for www.barackobama.com, so in theory, it's legit.

<comment><AUTHOR> To be honest, I got it from Barack Obama's AMA on Reddit [http://www.reddit.com/r/IAmA/comments/z1c9z/i_am_barack_obam...](http://www.reddit.com/r/IAmA/comments/z1c9z/i_am_barack_obama_president_of_the_united_states/), so the endorsement of the website comes from the POTUS himself.</comment></comment>