DEV Community: Grant Lipelt

Deep Thinking / How To Be A Better Software Engineer

Grant Lipelt — Sun, 06 Sep 2020 20:04:38 +0000

Over the years you get to understand what 'works' for you and oftentimes you'll only later find that what works for 'you' often works for 'others' and is also known by 'others'. And sometimes, decades after you learn these tricks and techniques you discover that they are readily known and even recorded in print. Here are a few techniques that can improve your thought process, translating into better software products and contributions.

Thinking In Motion

My first job in software engineering was at a 40-acre engineering facility, a series of buildings covered by a massive superstructure. Rain, sleet, or snow you had 40 acres of walking available, uncompromised by environmental conditions 24/7. The typical ritual was a lap around the facility after lunch seemed to evolve into a routine whenever you hit a mental block. Struggling on a design or implementation often meant figuratively, or sometimes literally, banging your head against the wall.

So there you are, trying to work out a troubling problem, frustrated and in time the frustration turns to a bit of anger. Surrounded by your office mates, your workspace is no place to lose your cool so you decide by happen-stance to take a walk, mostly just to relocate to a place you can grit your teeth and maybe cuss a bit under your breath. Your focus, still on the problem at hand, but now you're out and about thinking, venting while in motion. Like the sun pushing through the dark and stormy clouds a solution begins to emerge, first as a glimmer of possibility evolving into a full-blown solution. Now, armed with a solution you double-time it back to your desk reinvigorated and supercharged to prove it out.

Weeks pass, you find yourself in a similar situation; puzzled and frustrated, you take a walk, arrive back at your desk with a solution and implement it on your return. Again, and again, this proves to be an effective process for you, and as far as you're concerned it works exclusively for you. Later, you find your co-workers have arrived at the same process. Later in life, you learn this exercise-based thought process is well-documented by the likes of Scientific America and such.
In general, even mild exercise increases blood flow which energizes the old cerebrum and hippocampus and pull you out of your mental funk.

Thinking in a Free Space

You spend a good portion of the day trying to solve something, but it continues to evade you. Tattered and defeated you pack up for the day, make your way to your car and begin your commute home.
You can get stuck on a small number of associations that aren't working when consciously trying to remember something. When you relax, your mind more freely and randomly associates, which gives it a chance to find a different association to the information then the fruitless ones you were consciously pushing on. A guilty pleasure comes on the radio and you proceed to car dance your way home to a Hungry Man's dinner and a cold beer. Mid-song you're hit square betweeen the eyes with a solution to your day's problem......BAM!! Like your 'take a walk' process, this happens again and again, and you're left with "why the heck does this work?".

Some say that the reason this works is that your brain is an association solving machine. Sometimes you get stuck on a small number of associations on the conscious level that won't solve your problem, but you continue to try to make them work and continue to fail. Then, your mind set free by a ridiculous radio song it is free to more freely and randomly find associations and possibly landing on a completely new thought that will solve your problem. Sometimes, the best way to solve a problem is to set it aside for a bit and 'background process it'.

Thinking in Speech

You find yourself stumbling with a problem and under the prodding of your manager you reluctantly take a walk over to your coworker for an assist. You're not sure how to solve it and begin to explain the problem to your teammate, you describe the problem, you describe what you've tried and mid-sentence you stop, a new solution comes to mind and you return to your desk. The act of verbalizing the problem and your thought process opened new doors and didn't even require a contribution from your teammate. Sometimes simply talking the problem out outloud allows you to arrive at new solutions. A newly found thought trick, goes right into your personal toolbelt. In time, you later find others have arrived at the same tactic and it is often known as the 'rubber ducking' principle as described in the 'The Pragmatic Programmer'. The audience of your verbal mind-dumping can be a teammate, your bartender, a reluctant spouse/partner/date, your pet or your given choice of any given inanimate object.

Thinking in Print

I've never known a software engineer that likes authoring documentation, perhaps they exist and are but elusive, or perhaps they simply don't exist in this universe. Despite a general distaste of writing documentation, we tend to recognize its value and necessity to quality software and will do so reluctantly. I find, despite not liking doing it, that the sheer act of writing stuff down betters your design. You are forced to describe your architecture, your classes, their responsibilities, their interactions and you find yourself internally challenging your design 'why did i do this', 'what if i had done that', 'what are this particular classes responsibilities'. In doing so, you leave with a list of refactoring opportunities and/or changes to the design and make the time to incorporate them, ending with a more robust and sophisticated product. I find this likely a simple extension on verbalization, as it gives you the same benefits.

These are likely but a few tips and tricks for supercharging your thought process. To my knowledge these tricks appear to be pretty well-known, some well-established and documented, some passed along via developer palaver over drinks. My gift to you.

This post was originally published here

The Extinction of Mentorship

Grant Lipelt — Fri, 04 Sep 2020 19:19:48 +0000

Perhaps 'extinction' is a bit strong, but I certainly feel it's on the endangered species list. I have a sincere hope that I'm way off and mentorship is alive, well and booming.

When I was a wee lad, growing up in fly-over land USA, my father was building and finishing our family house. My older brother was extraordinarily skilled in many things, sheet-rocking would be but one of them. He and my father would hang sheet-rock and finish it with a proficiency that truly amazed as we younger kids looked on. My father, in time, took pity on me as it was clear I wanted to try and he handed the sheet-rocking screw gun. Properly sunk screwheads were replaced with over-sunk, under-sunk and cockeyed counterparts. Clearly, this rookie was adding additional work to a proficient, efficient team.
The entire 2200 sq foot house required sheet-rocking, weeks of work I continued to assist, gaining proficiency along the way. To this day I'm convinced that my participation only slowed the entire process. The goal of apprenticeship is to exchange skills with the overall goal of eventually having a larger skilled staff. To be a financial win this means recouping the training costs with improved efficiency of the new staff. It's playing the long game, investing in your team with expected future gains.

Certainly there are other goals of mentorship, apprenticeship or training journeymen, but if you focus on it purely financially there are new challenges to the current world than that of the years past. Loyalty to company and loyalty to employees have taken a big hit these past decades so investing in apprenticeships has risk of net-loss. Like my sheet-rocking activity, the progress of our house was worsened by my participation; simply couldn't recoup the cost over a few weeks.

Active mentoring an apprentice takes time, likely a lot of time. I'm not talking an weekly meetup with a mentee with some inspirational quotes of a bit of advice. I'm talking daily involved monitoring and guiding an engineer in all aspects of the field.

I'm the engineer I am today because I was lucky enough to have a few mentors early in my career. Sadly, I've not witnessed real mentorship since, 14 years and counting, because all the teams I've been part of since have been senior-leveled experience.

So, where do young engineers go for advice? Reddit, slack, Twitter,...?

I'm looking for reassurance that mentorship is still alive and well.

Cheers.

This post originated here

How To Quit

Grant Lipelt — Mon, 31 Aug 2020 22:08:04 +0000

Some time back a colleague, who recently joined our profession, found himself unchallenged in his current role and threw his resume into the ring. Shortly thereafter he was offered a new job more fitting of his interests and asked me for advice on how to proceed with 'giving notice'. This post will revolve around that advice, expanding on it a bit.

Before we get into it, I find myself struggling to recall how I ever came to these opinions. School certainly didn't touch on such topics, and I don't recall ever engaging colleagues or mentors about the matter. Google wasn't nearly as popular as a junior engineer, nor Reddit, Twitter,....so I can only surmise that I came to these conclusions by means of sidebar conversations or personal conclusions. Being long-in-the-tooth I often take for granted such topics, but have no recollection as to how/when I came to such opinions. There is an entire world full of junior folks entering this, and every, profession that are faced with such questions, trying their best to do the right thing, and a general lack of good advice IMHO. Reddit subreddits on such matters are plagued with near-toxic advice partly because much of the community is under a lot of stress. So I'd encourage you, as professionals, to be approachable for the younger folks, offer them your support, encouragement and knowledge readily, patiently and promptly. Now, let's get into the matter at hand.

Assumptions

While every situation has unique qualities, I'm going to gear my advise to a graceful self-initiated departure with a goal of leaving on good terms. Sometimes deciding to leave a company can be easy, specifically when you hate your tasks, your boss or your teammates. Far more often I find it can be a difficult decision, I spent a little time on that topic in a previous post Intellectual Wrestling When Contemplating Leaving a Company if you have some time to burn.

General Guidance

I recommend some general advice, not necessarily hard-n-fast rules that can't ever be broken, but stuff I try to apply myself.

Keep Your Communication Positive, Professional and Honest

People change, organizations change, and while you may never imagine yourself ever working for this particular company again you may quickly find that the tech community is smaller than you initially think. I routinely find my old teammates working for different companies and while I don't particularly believe in the "don't burn any bridges or you'll regret it" advice, I have observed that people can be a product of their work environment. I've worked with folks that were terrible to work with at one organization but were completely different at another; people are capable of change. I've also known many-a-folk that have worked for the same organization on multiple occasions and the work environment has been drastically different between the instances; companies can change. Toxic elements can be replaced with better ones, bad managers can retire, quit, or be terminated for better ones. New management who are ill-equipped for the role may grow into becoming a great leader. Organizations can be organic, changing for the better, or sadly for the worse.
I personally feel that you should be positive and professional because you want to, not because you're expected to or forced to. Additionally, it's important to stay true to yourself. If you've been anxiously waiting 3+ months to tell your boss or teammate to 'shove it' and you'll regret not saying it, say it rather than live with the regret.

When leaving, you get to set the stage as to how much info you are willing to share. You can be as vague or as detailed as you wish, but I always encourage being honest. You can be honest and vague -- "I'm leaving for an opportunity that is better suited to my personal interests", or as detailed as you wish -- "I'm leaving because I don't have confidence in the financial outlook of the company.". One big factor, in my opinion, as to the appropriate level of detail really depends on whether you believe the organization/company/team will act on your feedback. I truly believe that companies want to be better and recognize that they need to be better. When companies lose customers and team members they should want to know why they are leaving so that they can take those factors into consideration and determine if they should or need to change. Imagine being a company with a revolving door of talented folks coming and leaving and not knowing why? That, my friend, is a recipe for disaster. With your upcoming resignation, you have a new-found sense of freedom that others may not share. You may know that the majority of your team is miserable for the same reasons that drove you to look elsewhere. You have an ability to speak on behalf of the team, and a good organization/team wants to know where they can improve (or what's driving folks away).

Deliver Your Resignation In Writing

Personally, I prefer providing a copy of my resignation either via e-mail or physical print. Often, a copy of your resignation will be placed in your HR folder, kinda book-ending your employment record. Additionally, I feel that exclusively verbal exchanges tend to lack recall of details, like when your last day will be.

I tend to follow something of the recipe:

announcement of resignation,
thank them for opportunities,
acknowledge talent of team,
identify final working day
optionally provide contact information

For example;
It is with regret that I hereby tender my resignation from [companyX]. I appreciate the opportunities this position has offered me over the past years and have thoroughly enjoyed working with such a talented team.

My resignation is effective today with my final working day of [last day date] unless it is felt an earlier separation date is more appropriate.

I wish you, my team and everyone at [companyX] all the very best for your continued success.

Short, direct and to the point. The purpose of this exchange is pretty limited, a graceful announcement of your resignation and final working date. The audience, your manager and HR typically. Team announcements and follow-up conversations tend to take place independently and later.

Preserve the Chain-of-Command

The term 'chain of command' has some pretty dated and perhaps negative connotations but it's worth preserving for a number of reasons. In a world of transparency and open-communication, the responsibility goes both ways. I've known folks that openly shared their job search details and upcoming resignation with seemingly everyone but their manager and personally I feel that's a bit unprofessional for a few reasons.
Your current and upcoming tasks need to find a new home, specifically someone to do them. Your manager will be responsible for doing just that, perhaps hiring your replacement, offloading your tasks to existing team members or re-prioritizing tasks to account for the change in the team. It's common professional courtesy to give them some time to get their ducks in a row before letting everyone else know. Give them time to prepare for the question "With Bob leaving at the end of the month, how will his tasks be handled?". Remember our goal should be a 'graceful transition' and giving leadership some additional time will assist in precisely that. Unless you truly hate the company, your team and everyone else for that matter, this additional time will reduce the stress on all those folks affected; if you like your team, give your leadership some time to come up with a transition plan, its more for your team than preserving appearances.

Process

I feel that the typical flow of events take the following form:

Establish a Final Work Date

A pretty typical convention is to provide your current employer with 2-weeks notice. Often, this is a professional courtesy rather than legal obligation. That said, it's of my opinion that it's best to preserve a 2-week notice if possible for a few reasons:

some company policies require it
some contracts (e.g. contractor agreement) legally require it
give time for a graceful transition, knowledge transfer, task hand-off Defining this final work date is typically done by getting a new formal job offer, planning a time to notify your manager and tagging on 2 weeks from that day. Job offer arrives Friday afternoon, plan is to notify your manager on Monday morning, last day is second Friday to follow. ##Author a Resignation Letter/Email Armed with your final day, you can author your resignation letter calling out your final working date to avoid any confusion. ##Deliver Verbal Resignation I've changed jobs a number of times in my career, to this day this step continues to come hand-in-hand with anxiety and discomfort, but you press through it.

Ideally, I prefer this be done in-person as I feel it is shows more respect. Managers can be overly busy, so I try to arrange it with pre-established private 1-on-1 meetings, or try to catch them when they have a free moment, requesting a private conversation and delivery the message.

Despite all the best intentions, sometimes this plan falls flat. Your new employer is expecting you on date X, you need to deliver your resignation on X-14 days and something can always go wrong. Your manager scheduled work travel and is across the country when you didn't expect it, a sick child resulted in him/her going home to take care of them, their schedule is packed with end-to-end meetings throughout the day. The best laid plans can often go off the tracks, this is where you may find a need to deliver the message off-plan; e-mail, to another party, later than planned...

Hopefully, if you are considered a valued member of the team you'll likely be asked a couple things; 1) why you are leaving, and 2) is there anything that would make you stay. It's worth putting in some time in thinking about how you would respond to such questions beforehand.

One final topic I always ask in this chat is "how would you prefer to communicate to the team"? Two things you're looking for: 1) when should the team be notified, and 2) by whom. Depending on your manager and organization, your manager may prefer to make the announcement, especially if you have customer and/or intra-departmental relationships. Otherwise, they may prefer you make the announcement directly to your team. That covers the 'how', it's also important to get a 'when'. Your manager may want a day or so before you tell your team, they may want to begin the process of hiring someone, they may want to re-prioritize activities, they may want to just spend some time on how to address your leaving. Be prepared to give them a bit of time to get their plan in play.

Deliver Formal Letter/Email

Immediately, or shortly after the verbal exchange, deliver the printout/e-mail to the your manager. Your manager will likely provide a copy to HR for your employee file and will use the last working date for notifying the affected parties (e.g. HR, leadership,...). Additionally, they may initiate a hiring process by authoring a job posting and coordinating it with HR.

Announce to Team

Initiated by an official announcement from your manager, or a side-note you offer via Slack channel, e-mail or during a daily standup. Typically, this is a short exchange, positive, professional with the direct goal of making everyone aware. Most often, this is short announcement to the group and throughout the day the team will reach out to you individually to share their opinions and feelings about your departure.

Handoff/Knowledge Transfer

With the clock running, you've acquired a great deal of knowledge and responsibilities that now need to find a new home. Typically, the team will be begin a desperate flurry of handing off your existing tasks and performing knowledge transfers. Having been responsible for a number of tasks, ones which you are counted on and accomplish well.....now your team is faced with how will they get done when you're gone? This tends to take the form of: you training someone directly, or documenting how you do it.

Exit Interview

Optionally, well-established companies will have an exit interview for departing employees. Good companies understand the value in retaining talent, so they want to understand why folks elect to leave. A big ol' pile of money goes into hiring someone new and training them to become an effective contributor, so people leaving is the equivalent of cash walking out of the door.

Often, Human Resources will conduct an exit interview with you, with the purpose of determining why you choose to leave. Those details are tallied and perhaps one-day applied to reduce employee turn-over. For example; If 80% of folks are leaving due to compensation, then the company can gather the information, establish the trend, and make changes to address the situation. Equally, they can choose to not act on the findings as well.

You are in full control of how much detail you wish to share, be as vague as you wish, or as detailed as you wish.

Final Day
The big day; you cleaned out your desk, preserved all your work, exchanged personal goodbyes to your teammates, and as a last act you will author your departing e-mail.

Normally, this last act is an e-mail calling out your final day, a form of gratitude to having the opportunity to work with the team, an acknowledgement of you learning a lot and a desire to keep in touch often with your personal contact information (e.g. phone, e-mail). This is sent shortly before handing over your equipment, badge, parking pass and someone accommodating you to the door. A firm handshake, a thank you, and you're off to another adventure.

This post was originally published here;

Intellectual Wrestling When Contemplating Leaving a Company

Grant Lipelt — Mon, 31 Aug 2020 21:57:02 +0000

Spending the past decades in a career focused on logic and reason it's disappointing and perhaps eye-opening to observe reasonable people not making reasonable decisions. As much as I'd like to mount my particularly high horse and proclaim from above how everyone should behave, self-reflection would only exhibit hypocracy as I'm guilty of some of the same short-comings. I'm still a pup in the study of organizational dynamics so I offer no solutions, only present observations specifically focused on justifying leaving a team which has a corrosive element. By no means should this be perceived as advocating leaving your team, rather it should be considered reasons you could consider leaving and remedy guilt you may feel in doing so.

Perhaps sadly, long gone are the days of long-term employee/employer relationships. While more common in past decades, I'm constantly surprised when encountering employee anniversaries on the 15+ year mark. While admirable, it's far more common for 5-10 year engagements in my observations, but I have no data to back up such a claim. The point is, company/employee loyalty or long-standing relations are less common than years ago and there is no societal judgement in leaving a job for another position. In fact, in my opinion, one of the worst things for anyone is to feel or be trapped to an employer/employee. The employment relationship should be mutually beneficial, if not it's time to consider splitting ties.

I'm getting a bit off-topic so let me reel this in. Suppose you're currently working on a team that is mostly good, but has some strong elements that makes it frequently suck. For example, suppose you like your manager, really like most of your team members, but has one (or a few) people make it miserable. Now what?

You're at a cross-roads; stay or leave?

There are strong merits to staying and participating in changing the culture and as admirable this path is, I won't be focusing on it; leaving it to countless other experts. Stay or go; it's a personal decision, one you need to make for yourself. Having struggled with this decision numerous times myself and seeing colleagues around me go through it as well it's a pretty common plight. I thought I'd share some of my thoughts on what may go through your mind and provide some counter-points to common concerns and feelings of guilt.

Feeling of Guilt Leaving the Team

Hopefully, there are team members that you genuinely enjoy working with. When this is the case I've often struggled with a feeling of abandonment, leaving your good team members to deal with the bad ones. A feeling that you should remain to assist in changing the team for the better. Despite the 'fork in the road' analogy the choice to leave can participate in changing the culture. Pain is a primary motivation, easily observed if you've ever encountered a freak hailstorm on a beautiful sunny day. Despite your overwhelming desire to stay outdoors, being pelted by hail motivates you to change your current situation. This goes for you as well as the organization. Leaving a position, unless it's irrelevant, causes pain to your team, leadership, and organization at many levels. Project schedules and risk will be impacted which will/should be relayed up the leadership chain. Time and cost to locate a replacement team member will hit your hiring manager as well as human resources. Training costs, formal or informal, will impact the organization. In the case of loss of an employee, rather than a contractor, often a 20% salary finders fee will be accrued, a pretty common fee associated with recruiters. Loss of a team member is a pretty visible event, while there are plenty of organizations that see this as simply a common thing, you NEVER want to work for a organization that trivializes employees leaving as a non-event.

If you hate the organization you're leaving and everyone associated with it you'll unlikely experience any feelings of remorse, but what if you genuinely like some of the people that will be recipients of the impacts?

What if you like your manager, aren't you hurting them? In a word, yes; but you may also be helping them. If a caustic team member is driving away good people it may motivate them to remove the bad element rather than feel everyone will simply deal. Even the strongest managers struggle with removing an employee for any number of reasons; hoping in time they will improve, a desire to avoid conflict, avoiding the time/cost to locate and train a replacement, a hope in time they'll leave on their own or a desire to avoid the crap-ton of red-tape in documenting and executing an employee dismissal. Sometimes it's not a shortcoming of your manager, perhaps the caustic employee works for another team. Like a neighbors dog, often the caustic team member is nice to his/her immediate family but bites everyone else. The neighbor will strongly desire to keep their family member until it's been demonstrated it bites someone, only then are they sufficiently motivated to address the issue. Leaving an organization is a public event and formally or informally the reason you choose to leave will make it to decision makers capable of addressing the root cause. If you have a dick working at the company that is driving away talented people it's simply a matter of time before people who can remedy the situation are in the know. Regardless of how instrumental they may be to the company, a repeated cost of hundreds of thousands of dollars of driving away good people will raise them into a stage they want to avoid. A company earning a reputation of being a revolving door of hiring is less tangible, but certainly one most companies will avoid.

What About My Team?

Regardless of how good you are, it's incredibly arrogant to ever think your team can't live without you. Will they be affected? Absolutely. Short-term they will absolutely encounter pain and likely through no fault of their own. In my opinion, this will likely be the heaviest burden of guilt you may feel when deciding to leave. Call it career survivors guilt, understandable but ill-placed. Long-term, your leaving may contribute more to changing the culture than staying and fighting windmills for years. It opens a door to find a organization that has a better culture and keeping an eye out for opportunities for your team to join you in the future.

What About My Reputation?

Maybe you're concerned that leaving when 'times got tough' will earn you a quitter scarlet letter. Having been on both sides of hiring, despite what your high school principle may have informed you....you have no 'permanent record'. Unless you live in an incredibly small community that is subject to gossip, the reasons you leave an organization are pretty confidential. The company you left will likely know, and future employment will only know what you share. Employment references are less common than days of past, and when given are often heavily restricted. Your past managers sharing the reason you left puts the company in jeopardy of liability.

What If I Can't Find Another Job?

Risk of not being able to find another job may be an issue, but if you're good at what you do and the market is accommodating I've always been confident in finding another position. You can remedy this concern by finding a position before tenuring your resignation. Timing of leaving a position for another should be considered, and while likely industry-dependent....avoid leaving near the end of the year when hiring efforts and financials slow.

In Closing

I hope you found some of this useful. Feel free to share your own questions or opinions on the matter. Keep in mind, this isn't advocating leaving as the only solution, rather hopefully it provides insight into how leaving a company can long-term benefit a company as well as counter-points to feelings of guilt you may feel when struggling with this decision. Having worked for a variety of companies these past decades, as an contributor, a technical lead and part of management I feel I have a wide angle lens on employee hiring/leaving practices.

Final note; I've worked for a variety of organizations and have never found one to be inherently evil. I've never met a Montgomery Burns who treats employees like replaceable cogs and doesn't want to address organizational issues. Most people want to do the right thing, sometimes it takes a sharp kick in the pants to motivate them to do so. Reputation and cost are universal motivators to organizations and may provide the tipping point to fix what ails them.

This post was originally published here;

Making Slideshows w/FFMpeg

Grant Lipelt — Tue, 25 Aug 2020 19:56:29 +0000

Browsing Reddit or StackOverflow and you come across numerous posts asking how to generate slideshows with FFMpeg. Seems a common interest and incredibly easy with the right tools. FFMpeg is one of the said tools,the other....makefiles.

There are few utilities that are truly hated in this industry, makefiles seem to be one of them. Despite it's poor reputation, make is a perfect utility for many image and video processing pipelines. I blame it's bad reputation on the hacks that claim to maintain them. Make is the perfect utility, it's dependency engine is a perfect match for creating videos from input media.

This short little makefile will convert all JPGs in the current directory into subvideos of 1 sec durations, then concat them together into a long video and finally adding audio.

$ cat Makefile
SRCS=${wildcard *.jpg}
SIZES=$(subst .jpg,.jpg.size,${SRCS})
CLIPS=$(subst .jpg,.mp4,${SRCS})
SlideDuration=1
FPS=25

all: video.mp4

video.mp4: slideshow.mp4 audio.aac
${SH} ffmpeg -i slideshow.mp4 -i audio.aac -shortest -strict -2 $@

audio.aac:
${SH} youtube-dl -f best https://www.youtube.com/watch?v=IYbE2coMZPc
${SH} ffmpeg -i Íslandsklukkur\ (Instrumental\ Icelandic\ Folk\ Music)-IYbE2coMZPc.mp4 -vn -codec copy audio.aac

slideshow.mp4: ${CLIPS}
${SH} for f in echo $^; do echo "file '$$f'" >> filelist.txt; done;
${SH} ffmpeg -y -f concat -i filelist.txt -codec copy $@
${RM} filelist.txt

%.mp4: %.jpg video.size background.jpg
${SH} ffmpeg -y -loop 1 -i background.jpg -i $< -filter_complex "overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2" -r $(FPS) -vframes $(shell echo $(FPS)*$(SlideDuration) | bc) -an $@

video.size: ${SIZES}
${SH} echo $(shell cat *.size | cut -f 1 -d 'x' | sort -un | tail -1)x$(shell cat *.size | cut -f 2 -d 'x' | sort -un | tail -1) > $@

%.jpg.size: %.jpg
${SH} mogrify -auto-orient $<
${SH} identify $< | cut -f 3 -d ' ' > $@

background.jpg: video.size
${SH} convert -size $(shell cat $

clean:
${RM} *.mp4 *.size background.jpg *.aac

This makefile works for an arbitrary list of image sizes, it first auto-orients images (portrait/landscape) as it's not uncommon to have phone images mis-oriented. It then generates a *.jpg.size file that contains the image dimensions. These files are used next by the video.size target, which generates the maximum image size...this allows creating the video to match the largest of the images. Next, a background jpg image is created of said dimensions. Next, each image is converted into a 1 sec video which is then concatenated into the slideshow.mp4 file. Finally, an audio video is created by downloading a video from Youtube and the audio is extracted, then applied to the slideshow mp4 file to get the final video.

I dumped our Iceland photo archive into the directory to test and it spit out the following video;
https://youtu.be/RS4v9YB1rAA

Now, go out there and create something cool!

This article was originally published at:
https://dragonquest64.blogspot.com/2019/10/making-slideshows-wffmpeg.html