Looks like you lack visibility on what's happening on a day-to-day basis. Try setting up a task tracking process, daily status meetings where everyone can look at the task board and report their progress. Set up a lightweight Kanban-like feature delivery process. This will give you tools to understand the development pace and some useful information for the release planning as well.
We had the same problem here. What we implemented is:
1. Have a separate step on the project management board describing "In Review" (QA) and "Deployed" (in production)
2. Interested parties (sales and marketing teams, for instance) should have "Observer" access in the ticketing system and follow relevant issues
Alternatively, you can ditch the Observer access and do the release notes based on what was "Deployed". If learning how to navigate the ticketing system generates friction for your interested parties, this can work better. Not an issue for us as everyone uses the same system to track their tasks.
Glad to help! Feel free to shoot an email if you want to chat or throw ideas around about this or other issues you may be facing as a new CTO. The address is on my profile.
Hi Daniel. Thanks a lot for the comment. This makes sense. We all should choose right tools for the right job and architect our solutions according to the requirements and restrictions we have.
One of my original goals was to make the financial entry-barrier as low as possible. Another — to provide educational context for covering a full-stack IoT development from firmware to backend to frontend. This means using cheap hardware and open-source software. In fact, I spent around 9$ on everything that was needed for this project.
I wouldn't say that this project is over-engineered with cool tech. I tried to keep the setup as minimal as possible, sticking to industry-standard data exchange protocols and frameworks.
Of course, all of the software part could be written using ANSI C or C++, but from my point of view, it wouldn't make the project simpler, because there are more specialized tools that are better suited for the particular task, be it backend, frontend or firmware (Rust, HTML5+JS and C in case of this project). I have outlined rationalization behind this particular technology stack under the "Choosing the technology stack" heading.
You are right that in a commercial setting, there might be myriad more inputs that constrain the technology choice like team experience, your company's recommended technology stack and etc. Of course, we can't take into consideration all these hypothetical requirements, as they depend on the environment you are working in and the commercial goals of the project.
To make your comment complete, could you share your ideas on how to architect this alternatively to get the same result with less than ten bucks, maybe an hour or two, and just a handful of code, if any? If it is a viable alternative I'll consider adding it into the post as an alternative tech stack, so people reading it will see more alternative options on how to build this project.
Thank you for taking my comment in the spirit it was intended. I'm happy to oblige you.
If your goal is to play and learn about stuff, whatever you're doing is fine.
If your goal is to get basic weather information, buy a used weather station with usb access, plug it up to whatever hobby computer you already have (I have a pi, so I'd use that). Then write a cron to read from the station and write it out to some publicly-available spreadsheet or database. There are a bunch: Google, Airtable, and so on. Most all of these can be written by one POST.
Then you can figure out how you'd like to see the data. Add in a station ID for more fun and a distributed system. I'm seeing Ebay new weather stations as low as 24 bucks or so. That'd be the only cost I know of, and I think with some searching for used gear you could get it under $10.
There's a _huge_ difference between focusing on the problem and focusing on the tech. If you're preparing yourself for a world of corporate coding? Please keep learning about message queues and so forth! You'll need those skills. If, however, you just want to know the weather in various places with your own setup? Do that. Just don't do one of those things while pretending you're doing both. Each project has vastly-different parameters.
To drive this home, if I've decided I want a coder to come to my office and make a cool little way of telling the weather outside? I want the project that just does that. Code for an hour or two, then leave. If you come and start deploying a kubernetes cloud-based auto-scaling megasytem, you're coding for yourself instead of my problem. My only point was that since there is such a huge gap, when you teach people you should be clear about the hidden lessons of what you're teaching.
* Now traditionally programmers throw out a lot of "what if"s here. What if we needed split-second reports? What if we're dealing with an offline situation or a saturated net? All of those are great considerations. Also, all of those were not included in the spec I read back to you. Don't go inventing what-ifs where none existed. It's a good way to build unmaintable monsters. Hopefully you got the point. It was a minor point and not directed at you, just a comment on cool-tech articles in general. (Also, I'd love to demo actually building it, but it would probably be quite less dramatic and interesting than your version, for the reasons I explain above)
Keep up the good writing! Looking forward to reading you again.
