I think it’s important to work some fun into programming projects.
Give yourself permission to build something that already exists,
if only to learn how to build it yourself. It doesn’t have to be
a big serious project, or a perfect portfolio piece.
And on that note, don’t be afraid to hack things together. It’s
a fun project! Write some terrible code that you know is terrible.
Don’t stress so much about perfect abstractions and Best Practices
and feeling like you have to incorporate every new library and tool.
It’ll be fine. You can always refactor it when you write the blog post ;)
I think it’s important to work some fun into programming projects.
Give yourself permission to build something that already exists,if only to learn how to build it yourself. It doesn’t have to be a big serious project, or a perfect portfolio piece.
And on that note, don’t be afraid to hack things together. It’s a fun project! Write some terrible code that you know is terrible. Don’t stress so much about perfect abstractions and Best Practices and feeling like you have to incorporate every new library and tool. It’ll be fine. You can always refactor it when you write the blog post ;)
I always wanted to be better at software engineering, and software design, and getting abstractions right, and all that stuff. I've slowly gotten better at all that, but I didn't know it would come with the tradeoff of being unable to switch it off.
He's a very good engineer and this was well within his ability, but he became hamstrung by the hackiness. He continually complained that it would be unsupportable (I know), that he would be asked to make changes (no: this was explicitly part of the agreement with the customer) and it was a bad design decision (yes!).
By the time 4 o'clock rolled around, he had made little progress on his well engineered and future-proof solution and I didn't want to be there late, so I offered to take it from him, finished the hack by 4:30 and pushed it to the customer.
Customer loved it; greatly appreciated that "we had dropped all our work to put two engineers on their project" and it did exactly what they needed to demo their own product.
I guess my point is that engineering is about getting stuff done. Sometimes, if you know time is more important than anything else, your only choice is either cut corners or don't ship. Being a day late can be the same thing as never shipping in some cases.
It's when something that is being designed and built with the intention of a short lifespan ends up being around for a long time, and causing problems for longer than it was intended to exist at all.
And I think this happens all the time.
I think you did the right thing (I would have too), but unless you have solid consistency, work ethics and a great memory, you may put in that quick fix and it never gets improved.
If the quick fix stands the test of time, then it was the right fix regardless of how fast it was done.
I guess that is why I have grown into the approach over the years of always.. ALWAYS checking expectations thoroughly, even when it hurts a little.
It's important in the early stages of problem analysis to know - 1) how long do I have to analyze the problem? 2) how long do I have to implement a solution to the problem? and 3) how long does the solution need to last? Of course there are a million other questions, but I think it needs to start there. Of course, while answering those questions, as a service function, we must always be thinking... hands down.. what is in the best interest of the customer (which can be subjective, but it must always be the forefront)?
If you are given constraints for those 3 things, you can more accurately come up with an appropriate solution. My experience with this is hard-earned from just doing and always having to get creative.
Sometimes, I plain ask people - do you want a long-term solution, or a short-term solution? If you can come up with 3 options quickly based on your experience - short/mid/long-term and give the pros and cons, I've found most business users like this approach. Some prefer to just be given an answer and have the issue handled immediately - however, that isn't always the best for them nor the people doing the work. But, as they say, sometimes it comes down to "needs must".
i think that's a big part of programming as a career, learning to know when to make something run flawlessly, and when to make it just... run.
Or learning that user has a very different meaning of flawless, and that is almost always the more important definition.
Mediocre now beats great tomorrow more often than not.
Totally Crap -> Less Crappy -> Just Crap -> Starting to get half decent -> Actually not too bad and working -> EOL
This reminds me of Patton's Law of Program Planning from Akin's Laws of Spacecraft Design:
> 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
Put in another way of saying it, when you get tired of the constant pace of change of our toolsets, it becomes more about the problem and solution rather than the specific tool you use to solve it.
Don't get me wrong.. I still do love learning all the latest and greatest, and keeping my hands on the tools. But over time, after a long time of getting distracted (or even disrupted by the "need" to keep learning new stuff), I feel at least that it can get tiring and to the point of interrupting any actual productive labor towards a bigger goal. So I agree with you.
I started a react project a few years ago and opted against Redux and whatnot. As the project grew and grew it became harder to maintain. Piece by piece, I self identified a 'best practice' that would solve a real problem I had.
I'm all about using React without Redux when it makes sense, and especially at the beginning of a project. Heck, I wrote a whole book teaching React that way, and it's how I learned it myself. Wanting to use the "best practice" libraries is a different angle than what I meant though, which was more like a background thread running in my mind about how I should be refactoring things as I go. Two sides of the same coin though, in a lot of respects.
And if it's stupid and it works, it's not stupid.
Like other large tasks, the only way I have found to get hem done sometimes is to just start on a little piece without overthinking. This can be at the beginning or in the middle of the project.
So, just in case you're feeling guilty for over-engineering this, it could have been WAY worse, hahaha. This is the just-right level of overengineering.
"Doohickey - CLI app written in C++, Boost, and the STL"
"whatchamacallit - an admin module written in JS, React, React Saga, Storyboard, Redux, Express, nginx, Electron and markdown"
"mugabe-rails - a library written in Ruby to parse JSON"
"lasagne - a meal made using cow, spaghetti, and tomato"
Instead, what I took away from it was something much more insightful and mature. He pretty much defined his most minimal MVP, committed to getting that working, and completely dispensed with the notion that he had to invest in the more fancy tech up front. He got a working solution for his problem and if needs be, it can be made fancier now it actually works for him.
Like you I was also keen to automate my WSM smoker, and ended up buying a £20 Inkbird PID controller, hanging the thermocouple off the lid and hooking the 12v relay output directly to an old case fan attached via ducting to one of the vents. For I now get temperature stability to +/- 3 degrees C, and fuel that used to last 3 hours now lasts 11!
My 2c aside, I really enjoyed reading your writeup, and I wouldn't have stuck with it and learnt as much had your chosen subject not been so close to my heart.
Another application I want to apply a PID to is coffee roasting, but that's a whole other kettle of fish.
EDIT: Oh wow, this one is only $16! https://www.amazon.com/Inkbird-All-Purpose-Temperature-Contr...
EDIT 2: Based on a review, it sounds like that $16 one won't measure temperatures above 210F. Bummer.
Disclaimer: I say this as a firm believer in the power of charcoal.
And the ones that can tell the difference, will inevitably go on to eat something else after the meal is finished.
It’s just not worth the time and effort unless you’re a hobbyist.
I haven't cooked pulled pork in a while, but I have been making some pulled chicken in my pressure cooker every now and then the past few months. After 15 minutes on high pressure(~15 psi, 250 degrees), the chicken is fully cooked and literally falling apart as I pick it up under its own weight, which is something I never get even when I smoke chicken in my digitally controlled electric BBQ.
On a side note, I can get boneless skinless chicken thighs for $1.50/lbs, and cook up a big pile of delicious meat in 30 mins that lasts a week. Highly recommended for the cheap, lazy, or people who just like pulled chicken.
Pressure cooking lets the internal temperature rise faster by suppressing the boiling on the surface.
Of course! It would totally demolish "the stall". I have a pellet grill, and I'd love it if it had a high pressure mode that would kick in, sealing off the vents, once the internal temp's rate of change slowed to a certain point.
I have a stew that would normally take 3 hours simmering on the stove that can be done in 20 minutes in a pressure cooker.
+1 for OP's thermometer manufacturer Thermoworks, I'm a happy customer as well (and unaffiliated).
As an aside, if you're in the market for an electronic temperature measurement device, they're currently running a Father's Day Sale. (https://www.thermoworks.com/)
Nice article, thanks for sharing!
There are only so many namespace collisions I can deal with; that isn't one of them.
Though I have to say, my favorite pulled pork hack involves C, PHP, an Arduino, a Pi, a couple of thermocouples, and a fan controlled by a solid state relay.
Yours is simpler, and the photo part is really nice. But the fan control on the heatermeter project adds a whole other dimension.
I've seen some people using a fan that they modulate with a PID to control the temp, which is on my list of "someday maybe" projects, heh. I wanna say there's even an existing product that does this, but I forget the name.
Fairly easy to glue together sensors to roll your own, I made an egg incubator with basically the same pieces that had a webcam too, http://www.velvetcache.org/2018/03/04/chicken-cam-incubator-...
I like the reuse of the phone though, I wonder if there is some sort of bluetooth board out there that can bridge the phone to the gpio stuff.
I must admit though, that I forgot to apply the rub before I put it on the smoker! (7am me was groggy, and rushing) So I applied it about 30 minutes into the cook. Surely not optimal, but it came out delicious anyway so hey, whatever :)
I would recommend rubbing with oil before the rub, and not water. Most seasonings are oil-soluble and will work better if you've oiled them first.