2016-12-28Tags: #working Olsen Light WordPress Theme How to Create a Child Theme By wieldlinux.com author Morgan Jassen Recently after having replied to a support topic for the Olsen Light Theme for WordPress ( https://wordpress.org/themes/olsen-light/ ), I've been subscribing to the support issue feed for the Olsen Light Theme. ( https://wordpress.org/support/th.../feed ) Someone asked in a forum thread how to modify CSS for the theme. I wanted to reply that I think they should create a child theme first. However I realized creating a child theme is not always that straightforward. So I decided to figure out how to create a child theme for Olsen Light. The WordPress Child Themes codex page helped me -- indeed was my guide to build the child theme. ( https://codex.wordpress.org/Child_Themes ) A caveat that I ran into was that making the functions.php file, at first I thought I had been supposed to make a line as thus: $parent_style = 'olsen-light-style'; As it turned out, I just needed to leave it alone and paste it just as in the tutorial, as this: $parent_style = 'parent-style'; Here's a link to the finished child theme that I authored, including readme instructions: https://github.com/mjassen/olsen-light-child --- tags: #investing Thoughts on Having Read Rich Woman Book By wieldlinux.com author Morgan Jassen I recommend "Rich Woman"*, which I read, which is a book by the persona of Kim Kiyosaki because, through stories, the book humbly coaches the reader to empower themself to become wealthy and to become strong. Here in this blog post is a summary of the book, and mixed in are some of my thoughts. At 70 pages in, I knew it was as good as the "Rich Dad"** book. From the unique point of view of the persona of Kim Kiyosaki, the author tells the story of herself, her friends, people, women, rich dad company, and more. Through the telling of these stories, the book relates a valuable message. I liked that the book had a story feel to it. It's got stories of how she met up with her friends more than a decade later, and they discuss money, investing, financial independence, and more. It's inspiring. The main characters, the ladies in the main story line, have trust from having known each other years ago. Additionally, now they have life experience with things like: working for money, owning a business, saving money, raising a family, having money troubles, and investing. Despite this experience, many of the characters in the story say that they don't understand, and/or value, the concept of financial independence. That is, until their old friend (Kim's character) imparts it to them. The book's story (stories) resonate(s) with me since I've also had some familiar life experiences, and I also find myself being introduced to, or for the first time starting to understand, the concept of financial independence. Furthermore, for those like me who have listened to the audio book of Rich Dad (or read it), Rich Woman book gives a complementary, value-added look on it. Indeed, the Rich Woman book itself, within its text, refers to the Rich Dad book, and builds upon it. Furthermore again, the Rich Woman book combines the idea of humility with the idea of wealth, and gives the reader the feeling that the world is abundant with wealth and money enough for every person. The book explains what mindset to use, in order to tune into the universal truths surrounding these ideas. It's not just a book about money and becoming wealthy, but a book about becoming strong and being strong. In conclusion, I recommend Rich Woman book by author Kim Kiyosaki because, through stories, the book humbly coaches the reader to empower themself to become wealthy and to become strong. * Rich Woman: A Book on Investing for Women - Because I Hate Being Told What to Do!; by Kim Kiyosaki; Rich Publishing, LLC, 2006. ISBN-13: 9781933914008 ** Rich Dad, Poor Dad: What the Rich Teach Their Kids About Money-- That the Poor and Middle Class Do Not!; Kiyosaki, Robert T.; New York : Warner, 2000 --- 2016-12-23Tags: #stretching Once Again With the Water-Drinking from the Beaver Mug By wieldlinux.com author Morgan Jassen I previously blogged about "Seven Days of Hydrated Water-drinking Non-coffee..." http://wieldlinux.com/2016.php#2016-11-10 Result was positive-- I was off coffee for at least a few days, not quite a week. I talked about it. People asked about it. It was always within arm's reach, always with at least a little water in it. Mostly. One time I carried it but in my pocket, with no water in it. The end of the week, I stopped carrying it, and was back on coffee. Time to quit coffee again. So I'll start with this previous bit of success, and build off of it. I will aim for 1 week with the cup, then after that, to continue on beverage-water-only on my own. This time though, I'll do something else, something new to strengthen the process. Three times each day, as I do my morning, noon, and night stretches, I'm going to envision the taste and the feeling of yummy hydrating water. Every time I crave coffee, I'm going to immediately sip tiny, deliberate sips of water from the cup already in my hand. I'm going to grow healthy by replacing habits of coffee, with habits of water-drinking and stretching. Afterwards I'll plan to again write to follow up how it went. --- 2016-12-22tags: #mingling Viewing the Slideshow of a Professional and so Learning About Real Web Development Processes By wieldlinux.com author Morgan Jassen Following the persona of John Eckman, coming across this tweet (https://twitter.com/jeckman...880) led me to this 28-slide slideshow, which I viewed, and from which I learned about professional Web Development processes. This: "Distributed, not Disconnected: Employee Engagement for Remote Companies" ( http://www.slideshare.net/jeckman...remote-companies ) Some of my take-aways afterwards:
Close second is Scite
Third is Geany.
Note: This post was pre-published on 2016-09-25.
Note: This post was re-pre-published on 2016-10-28.
I want to do professional networking, make some professional connections, and make the connections last -- not many of them go beyond the group where we met. The professional relationships usually stay in the medium where they started. Next time at the monthly meetup I again say hi. Or maybe not. At least it feels that way.
How to bring my career professional networking to a "next level"?
Career remix!! Do it with peple! Network all the things!!!
Here are some ways that I have, or can, network:
There are a lot of channels there; how to focus my overall networking strategy?
1.) Continue calling individual people on the phone (like in: "For a Software Developer How to Network" (http://wieldlinux.com/2016.php#2016-08-31)).
2.) FOLLOW PEOPLE, (not projects/things/blogs/processes) Meaning, once I meet some people at a professional meetup or wherever, don't only wait until the next monthly meetup to contact them again. For one person with whom I got along well and was professional, call or email them before then to check in and ask what they're up to and learn from them.
3.) Move away from only blogging on whatever I want, all by myself. Instead, after having talked with someone about a topic. Later, blog about that specific topic. With the person's permission, find out whether or not the person would agree to me mentioning them in the blog. If they say yes, mention them in the blog post. This way, it is networking at the same time as blogging!
4.) On twitter, tweet @ people. Don't just tweet a link to my blog post and hoping someone sees it, instead tweet it @ someone whom I see tweeting about something related. Join in conversations on twitter. @ people is the key.
5.) In general, online, don't just read. Reply there. Join in the chat conversation. Calmly voice my professional opinion on professionaly relevant topics.
6.) Read .org forums then reply, the goal being to connect with the person. Find out who I'm replying to. Look for forum posts written by people who are active on their own public channels like blog or twitter, etc. Follow them on their public channel and if they write with professionalism and if it resonates with me, then publicly comment over there.
8.) Make it about the *PEOPLE*/PERSON. At an in-person event or online, always be looking network by having a conversation with someone. ( As opposed to just going to the group and listening to a speaker's talk and then going home) In addition, talk about the event or the project with someone, both before & after. Always. This is what makes it networking as opposed to mere media consumption.
9.) At an in-person meetup, ask someone where they publish online, or how to reach them after the event. Afterwards, I liked what they had to say and if they were professional, then read what they're up to in their public online space. Comment back to them there. To be genuinely interested and curious, I should seek the person on *their* preferred online public medium. So, if they like to blog then I can follow their blog and comment to them. If on their about page they publish their email address welcoming feedback then I can email them telling what I think of their blog post.
Finally I should remember it may be structured professional networking but it shouldn't be forced or non-genuine. Personally I have had bad experiences with a conversation trying to be forced (from both ends -- at times I've been the person trying to force a conversation, and at times someone has tried to force a conversation with me). That's unpleasant, akin to meeting an overly-pushy salesperson. If there's no professional chemistry, don't force the conversation; drop that thread. Chase the conversations where there's chemistry there!
These have been some ideas that can form a strategy of how to, as a Web Developer, advance my career through networking.
Note: This post was pre-published on 2016-09-25.
Note: This post was re-pre-published on 2016-10-28.
I re-did my Software Development and Support Engineer resume by doing a TJD (Target Job Deconstruction), and an unexpected side effect was that it helped me with my current job.
In order to update my resume, per the advice of "Knock 'em Dead" job seeking (career development) book ( by Martin Yate), I performed a TJD.
I expected it to help me to craft an excellent resume and that's all.
But in addition to that, it also made me become more engaged in my current job.
How did it do this? In doing the TJD one night, while looking through job requirements for 6 job descriptions similar to my target job, I found that two of the requirements I was weak on.
And furthermore, for one of those two, although I hadn't ever had direct experience, I recognized that my colleague's project from that very morning was fulfilling that requirement!
Of course, the next day, I made a point to ask my colleague how that project was going, what details they could share, and how I could help.
Thus because I deconstructed my desired role off-hours, I knew clearly what I needed to work on & learn about next!
This is a *specific* example of how reading "Knock 'em Dead" book, generally is good for professional development *regardless of whether a Software Development and Support Engineer is currently seeking a job or not*. This is how doing a TJD (Target Job Deconstruction) helped me with my current job.
Note: This post was pre-published on 2016-09-22.
Note: This post was re-pre-published on 2016-10-28.
In October 2015, I found something that I had deemed important, such that it would probably take my time away from WordPress for months. I thought I’d need to stop participating to WordPress forums and WordPress chat.
Transcript in the Slack archives from when I wrote that I had to take a break from WordPress. https://wordpress.slack.com/archives/...458 (A Slack account is required – see: https://make.wordpress.org/chat )
I had worried that career development would suffer during this 90 days. I wouldn’t be learning via the WordPress community participation.
Even so, I felt I’d still be learning in other ways. I felt I’d keep talking to colleagues via other channels and meet new friends and colleagues along the way. And I felt that I might learn things and do things that I’d continue blogging about on my Software Support and Development Engineer -related professional blog.
It immediately turned out that it was in a sense liberating to clear my calendar of the weight of the WordPress “school”. Then immediately I felt weird that I had thought WordPress activities (“school”) was highly important, but now that I had started to think something else was more important, that I could drop WordPress like that. Sort of emotional – sort of made me want to laugh, and cry.
At the same time I felt liberated, because that was the underlying motivation to learn about WordPress in the first place — as a way to learn about Software Support and Development Engineer -related topics.
I wound this down by doing a couple of things: Took WordPress reminders off my calendar, and removed WordPress bookmarks from my browser.
I had thought it was like the then-current home page of http://blog.josemcastaneda.com/ (Jose M Castaneda blog)
“…I am a WordPress fanatic. I love to learn new things and love to share my learnings. I have always loved open source and have a love-hate relationship with it. I hate how much I love it, sometimes. …”
I thought maybe it had turned out that I too sometimes hated how much I loved WordPress, and maybe that’s why there was some relief in the idea of taking a break from it for some time.
That’s what happened in October 2015 when I had found something that I had deemed important, such that it would probably take my time away from WordPress for months. I stopped WordPress community participation for a while. It felt sad yet liberating. And I re-discovered the essence of why I do WordPress as a type of “school” in the first place — to learn about Software Development and Support.
Note: This post was pre-published on 2016-09-09.
Note: This post was re-pre-published on 2016-10-28.
--- wieldlinux.com For a Software Development and Support Engineer What About Making Networking into an Asset and Placing a Dollar Value on It? To become serious about the value of networking, the following is an idea how a Software Development and Support Engineer (SDASE) might use money as a catalyst for professional networking. Let me start by saying AHAHAHAHAHAHAAAAAAA!!! That's what I sounded like out loud when I began thinking about this idea. I'm a Software Development and Support Engineer (SDASE) who's historically shy about professional networking. But I think professional networking's extremely valuable. But some other people think it's valuable, and some others don't. How to break the ice, approach others about networking with me, and explicitly express to my colleague that I value their networking with me? I will pay them money. The answer is that I can offer to pay my colleague to talk with me about professional career topics. For example I will offer a coworker $1 cash for every time they listen to my answer after having asked me the question of "how is the project going?" That's it. There will be caveats and exceptions. Like some colleagues may be offended, or some may be too busy etc. However, I think some colleagues will appreciate the playful yet professional aspect of this idea, and maybe, the idea of the dollar value is what will make the difference in playfulness to get them to agree when they otherwise wouldn't have! Or twists/variations may arise, Like treat a colleague to a coffee instead of $1 cash. Or a variation like pay a colleague $1 to be my "wing person" -- accompany me to a local tech meetup. Or maybe the colleague wants $5. Or however much we agree it's worth! Or of course, it will work both ways -- If my colleague offers me $1 to listen the description of how their professional project is going, or to be their "wing person" to a tech meetup, then I can consider doing so. The idea of monetizing professional career networking among SDASE colleagues fits inline with the whole idea of us all adding value to our careers; indeed, there is symbolism in adding a dollar to my or my associate's pocket, while at the same time adding value to the depth of our professional relationship. The point is, this idea could be used by me as I'm upping my game and becoming serious. I'm becoming serious about communicating the value of networking, and becoming serious about using money as a catalyst for professional networking. One more strategy for getting out there and networking professionally! This idea is an experiment. How could this work out, or how might it fail? Hahahha I just realized this idea might have been inspired by last night me having watched the "Mad Men" tv show episode where the Peggy character and them go to Burger Chef, and pay customers to tell them what they think about Burger Chef -- Marketing research. In conclusion, to become serious about the value of networking, a SDASE might using money as a catalyst for professional networking. Note: this blog post is dedicated to the folks over at supportdriven.slack.com, for week 1 of the 2016 6-week writing challenge. (more details here: "Stretch your Typing Fingers – Support Driven 6 Week Writing Challenge" ( https://supportdriven.com/2016/10/21/stretch-your-typing-fingers-support-driven-6-week-writing-challenge )) tags: #challenge, #mingling
I developed an interest in how Automattic company does Software Customer Support. I listened to an audio recording of a book popular in WordPress.com Happiness Engineer (Software Customer Support Engineer) employee circles: Hsieh, Tony. “Delivering Happiness:A Path to Profits, Passion, and Purpose”
I enjoyed the early chapters. They focused on the broad topic of “profit” and mostly were stories of Tony Hsieh’s entrepreneurship through the years.
Then I also enjoyed the middle section of the book which focused on “passion”. Stories in this part of the book were sometimes about how Tony got interested in Zappos company and how he an his colleagues grew it in its earlier years.
The last part of the book broadly focused on “purpose”. And parts in the middle-to-end of the book started talking heavily about Zappos company culture, events that transpired at Zappos company and with its people. I have to say that some parts in the middle-to-end I didn’t enjoy as much.
The three parts of “profit”, “passion” and “purpose” were mentioned by Tony within the book– I didn’t create these labels.
What(‘s) (are) my take-away(s), and what did I think?
Over all, I very much enjoyed the book.
How does it relate to Software Customer Support, and, why does a Automattic Happiness Engineer like to read it– and what from the book can I apply to my own role as a Software Customer Support Engineer?
A big take-away on software customer support from the book is that customer support can be a way to differentiate one’s company. A story from the book comes to mind when Tony Hsieh encouraged a non-Zappos friend to call Zappos and ask where’s the best place to order pizza. And the Zappos phone agent hardly missed a beat and did help the caller friend look up a pizza place.
Another take-away is that Tony says the company put a lot of resources into building a library and building a set of courses/classes, and effort to hire within and to encourage employees to move into higher-skilled roles in the company. My thought at this point of the book is that I wished to know more about how the employees viewed the courses/classes. At this time the company was hundreds of employees. I wanted to know more about how the employees view the courses/classes, and who among the employees participated in the courses/classes.)
I guess I’ll have to keep thinking about it, maybe read the paper version of the book later.
Note: This post was pre-published on 2016-09-09.
Note: This post was re-pre-published on 2016-10-28.
For a Web Developer work conversations should be in the context of the company's bottom Line. (In the context of how one's work adds to the company's profitability)
When the boss asks "how are things", really the boss means "How are things in terms of your current project adding to the company's bottom line?"!
Is it really my job to listen and talk in this context?
Is it also my job as Web Developer *to realize* (to figure out) that is that is the context that's being used -- to realize what is really being asked?
Yes. That, too -- the figuring out-- is also the job of the Web Developer -- is my job.
In conclusion, as a Web Developer it's my job to converse about my daily work in terms of how it adds to the company's bottom line, also my job to have figured this out..
Having thought this through, I feel good, and feel able to do my job and grow my career!
To give at least some quantification context to this post. This article "2015-2016 Dice Salary Survey" wrote that: "...Average technology salaries in the U.S. [increased] to $96,370 annually..." ( http://media.dice.com/...-salary-survey/ )
So take an arbitrary scenario where a Software Developer's yearly salary is currently $96,370.
Is it a switch where the Developer is either paid $96,370, -- or else isn't employed?
Or is it a dial where the Developer could either somewhere in a flexible range that is extremely loosely surrounding $96,370 -- could even be half that or could be double that, -- or else isn't employed?
*and* who controls the switch/dial?
The hiring manager? HR person? Employee? Of all three in a joint meeting? Or?
In professional life, I want to do something that improves my life or that is required of me, but that no one else does. For me it has in the past specifically been either taking a power-nap, or doing 2-mins-per-hour of yoga-stretching-exercises, or daily writing-and-sending my weekly report to my supervisor.
How did I realize that I have insecurity surrounding these types of exercises? These are things that I want to do hourly or daily. Consistently. And as such I know I'll be judged by my peers for doing them and for doing them on a consistent basis. And that people will talk about how I do these things -- my character will be defined by my habitually doing these activities.
I realized from reading the concept of HRT from the book "Team Geek" (Sussman and Fitzpatrick), and from my experience, that this is insecurity.
Solution? If it's important, then do it. The three above are examples. Stretching for two minutes per hour is important for my health so I should do it throughout every day. When I'm burnt out, taking a power-nap is important so on those occasions I should take a power nap during my break time at work. As the sole employee under my supervisor, if I am asked to write a daily report to my boss of what I've done, even when I know my nearby colleagues have not been asked to do the same for their supervisors, then I should do it. I should do it and if colleagues judge me as the person who does this and it becomes part of my identity, then I should acknowledge that and keep doing it.
Persevere with confidence. It's work, it's not easy, it can be uncomfortable. Colleagues will judge me for what I do and don't do. But a professional works through it -- indeed that's what makes them professional.
This has to do with improving a Software Developer’s soft skills, has to do with how to talk more with others.
In another post I wrote about how to do networking deliberately
and on to do it on a schedule. ( For a Software Developer How to
That’s another topic — this post covers one specific part of that previous post.
Today’s tip is to, when calling someone to network, make sure to *explicitly mention that the reason I called is to say hi, to ask how they are doing, and to chat*
The key here is to tell the person up front that’s what I’m doing.
That way it’s not weird that I seemingly spontaneously call the person. Also saying this up front clears the air and sets the expectation — I’m not calling to sell them something, and it’s not an emergency call, and I’m not calling to give them something — it’s a networking call — I’m calling specifically to say hi, ask how they are doing, and chat!
Interestingly I fisrt developed this tip for myself with phone call networking and not until later started to use it for in-person and written-correspondence networking.
The times I’ve used this tip, I’ve had good results with the person positively receiving this type of networking call.
Another tip is: to not take it personally if someone doesn’t respond or if someone says now’s not a good time or if someone says they’re busy.
However those are for other days.
Today’s tip is to tell the person that this is why you’re calling.
--- wieldlinux.com For a Software Development and Support Engineer How to Become Better at Something I recently wrote asking how salary is directly linked to professionalism. (See: “23 Questions Regarding American Professional Cultural Truths Around Performance and Professionalism and Identity and Pay Rate” http://wieldlinux.com/2016.php?2016-09-04#2016-09-04 ) So how to get higher salary? Up one’s professionalism. What if an SDASE is having a hard time– it’s been months or years and still hasn’t figured out how to up their professionalism? Research how to up one’s professionalism. What if one’s also not good at researching how to up one’s professionalism? Research how to become better at researching. In other words, the first step may be to step back further and research even more elementary such as “how to become better at something”. This is what I’m now googling– “how to become better at something”. Tags: #working --- wieldlinux.com 23 Questions Regarding American Professional Cultural Truths Around Performance and Professionalism and Identity and Pay Rate Is it a popular American cultural belief that a professional’s *performance* is tied to and determined by an individual’s professionalism? (professionalism here meaning an individual’s professional identity) Is a professional’s performance seen by one’s peers as being largely static? Is a professional’s professionalism seen by one’s peers as being largely static? Is the belief that some employees perform better/higher than others? Furthermore, is it that in general, within any given year for any given employee, the employee’s performance is expected to remain constant? Is it expected, however, that between years there may be changes in performance, which can be determined in a performance review? Is a popular American professional cultural belief that *pay rate* is tied to and determined by an individual’s professionalism — their professional identity — and is largely static? Is the belief that some employees are paid (and viewed as deserving to be paid) higher better/higher than others? In American culture, is it that in general, within any given year for any given employee, the employee’s pay rate will remain constant? ( but that between years there may be changes in pay rate, which can be determined in a performance review) In American culture, is it that an employee’s performance is seen as being not directly related to the employee’s salary? Is it that there is no *direct* relation between performance and salary, and that one doesn’t directly affect the other, and that any percieved relation is likely an indirect relationship based on performance’s / salary’s indirect relationship with professionalism? Are these truths correct or what? How close is this to the truth? Furthermore, in light of the above questions, then what about the following questions?… Q1. How can one affect one’s performance? Q2. How can one affect one’s pay rate? Q3. How can one affect one’s professionalism? Is A1. that an employee may affect one’s performance direcly by becoming professional or maintaining professionalism? Is A2. that an employee may affect one’s pay rate direcly by becoming professional or maintaining professionalism? How can an employee affect one’s professionalism? Is A3. that an employee can one affect one’s professionalism by listening to other people about being professional, talking with other people about being professional, reading books/texts on being professional, and writing/blogging about being professional? If one does the above, then during these listenings and talks and readings and writings, if they can pay attention and recieve attention to both the performance-related aspect of professionalism and the pay-rate-related aspect of professionalism, then will they become professional? Tags: #working --- wieldlinux.com Moving Web Server from Linux Desktop OS to Linux Server OS This week my Linux web server had been freezing up so that its GUI login console, as well as the web page serving functionality, had stopped responding. I saved db and files, and then did a reinstall. My server’s hardware is a netbook. It has no DVD drive. So I bing-searched and found instructions to install from a USB. I installed from usb. For the new server OS I installed Ubuntu Linux Server v. 14.04 lts. It has no GUI desktop. During install I used tasksel to install LAMP and SSH-Server. AFterwards I installed FTP server. Afterwards, I had to change a line in a configuration file to make it so closing the netbook lid doesn’t cause the laptop to sleep. I Loaded my MySQL .sql dump file with all the databases back into the new server using the mysql monitor. I FTPed the website files into the home directory, then copied them into the web root using sudo commands. I used chmod commands to set the directory and file permissions so that the web server can serve the pages to users. Overall I’m feeling comfortable with running my web server without a GUI. I’ve been able to get it up and running with only a few hours of effort. I’m happy because I think it’s going to run much better because I’m not serving my website from the a Linux desktop OS as I have in the past. I set the server to install security updates automatically as well. I have the extra satisfaction that I’m running server OS to run a server, which is the way it should be. I’m thankful that I was able to use Desktop OS as a server in the past– it helped me have the GUI to fall back to when I was learning to run a server. But now I’m comfortaguible running and administering the Linux server OS without the overhead and complexity of a GUI, it gets the job done perfectly, and it feels satisfying. Tags: #working --- In Order to Become a Better Software Developer Focusing on WordPress Plugins To become a better sw dev, I’ve curated a focused list of WP plugins that I follow as Thunderbird RSS feed support feeds. Tags: #working --- Professional Calendar and To-do List Makeover I’ve increased my productivity and preserved my sanity. I’ve done so by having made my calendar private, having stopped using recurring tasks, and having moved the to-do items into time slots. It’s much better. How? 1. I still use Mac Calendar for my to-do list and my Calendar events. I like how I can edit items either by drag-and-drop or by text-field & dropdown-selector. 2. I disconnected my calendar from shared cloud calendar accounts and disconnected the my calendar from email. Basically its on the local hard drive and not connected to any other calendar account or email. 3. I no longer use the “recurring” tasks feature. Instead, I tag it with a word that reminds me that it is a recurring task, like “weekly” or “daily” or “monthly” and as I finish each task I punt the task forward on the calendar. 4. I no longer use the “To-do” section at the top of the Mac Calendar. That’s the section at the top that’s meant for tasks that are assigned to a day but not to a particular time-of-day. Instead I put everything as calendar events with a time assigned to them in the main calendar event section. How does that all work and make it better and make it more organized? Regarding 2., above. Since I disconnected my calendar and made it local, this means Calendar items stay where I put them, and only appear, disappear, and move around on my calendar when I personally am the one to move them. I control my calendar items, so I’m in control of my tasks, my goals, my day, my career, and my life! A drawback to this is that I have to manually take the time to create or delete the item from my calendar. However that’s also the point- I have to actually look at, think about, and know about each and every calendar event, as it goes on or off the calendar, which makes me much more aware of my schedule and more careful of what goes on and comes off my calendar. The overall benefit is x100- I can really feel the difference! Regarding 3., above. How does that work, not using recurring tasks? So say its a daily recurring task. I do it done today. Then I drag the calendar event and drop it onto the same time the next day. What’s the benefit? The benefit is with one glance I see the *true number* of tasks before me. In contrast, before it appeared filled up with both one-time tasks and recurring tasks, with no way of telling them apart and I was hopeless. Now, I glance and I know how many tasks lie ahead of me and my calendar doesn’t feel full *so far in the future*. Regarding 4., above. How does that work, not using the daily to-do section, and instead giving every item a specific time-of-day? Well I still have tasks that don’t really *need* to have a specific time-down-to-the-minute-or-hour attached to them, but however that do need to get done as soon as possible. But it was confusing to have some tasks in the main calendar area and others in the top to-do section — my mind boggled trying to figure out whether I should be working on one of the to-do items at the top or one of the calendar events in the main area. 好累！ Now instead I assign each of these to-do tasks as a half-hour-long calendar event and I drag it and drop it roughly to the timeslot where I think I will be able to get it done. Also, I put a special tag in front of it that reminds me that this is a “to-do” item and is only roughly attached to the timeslot where I put it. I keep a manageable amount (half-dozen-or-so) of outstanding to-do items. I usually drag-and-drop them throughout the day and put them in a clump surrounding the 3-hour-long period of time when I think I can get them done. When I complete an item, I delete it off the calendar. When an important task comes along, I create an item for it and put it on the calendar clumped next to the others. Sometimes I have closer to a dozen outstanding to-do items so they take up much more space on the calendar or are arranged much more densely on the calendar, or both. I float the clumps of to-do list items to open spaces such as a large open mid-morning slot, or a large open mid-afternoon slot, or even an open night-time slot or an open early-morning slot. Maybe later I’ll be able to re-connect my calendar to my shared cloud calendar accounts and to my email, be able to take advantage of recurring tasks, and be able to stay sane while using the to-do area at the top. I envision this as happening organically, at such time when I again realize that I need these features. But for now, what I’ve described here above is working well for me. Well, that’s how I’ve changed my to-do and calendar work flow for the better. I made my calendar private and stopped using recurring tasks and moved all items (both to-do and events) to the main/bottom calendar event area. I love it! My productivity has risen and my sanity has maintained. Amazing!
For a Software Developer it’s important to network professionally.
Have a list of some people’s names with whom you want to network. At a pace which you feel comfortable (it could be three per day or it could be one per month; whatever is your style!) call the first person on the list, and first off say “just checking in” or “I’m calling to say hi and see how you’re doing. What’s going on with you?”
And then listen to what they say.
If no answer or I don’t have their number , then I either text or email a follow-up note.
The point is to stay in touch, be friendly, and say hi. This can facilitate you both helping each other – now or in the future.
This is how a sw dev can network professionally.
Ideally it can end in either of you landing a job now or in the future – through s friend of a friend. However that is a side effect of what’s going on here which is friendship, trust-building and prof networking.
Finally, move that person’s name from first to last place on the list. Repeat with the next name on the list at your own comfortable pace (But, make sure that you have the self-discipline to follow through and do it at regular intervals at this pre-determined pace).
Finally-finally, Note that some people won’t want to network. Either cycle their name down on the list to try when it comes around again, or, take their name off the list. We only want to network with those who are open to networking with us! Our goal is that as a whole, we’re not bugging anybody, we’re keeping it relaxed, and we’re networking professionally.
--- wieldlinux.com WordPress Plugin Development Recovery I completed a large part of the mzz-stat WordPress plugin. Now I’ve gotten a bit burned out from all this, and to recover, at home I am resting and reading the book “Professional WordPress Plugin Development” a chapter at a time. Tags: #working
Previously I wrote about:
To-Do List for Mzzstat WordPress Plugin
Here’s the link to the current revision at the time of this blog post writing: https://github.com/mjassen/mzz-stat/t...2745
Since then, I’ve done this::
– Added a changelog file and started writing the changes there as I do them.
– Removed hard-coded PHP MySQL database calls, replaced them instead with native WordPress database calls.
– Added plugin install logic and plugin removal logic, including code to install and remove the database table and data.
Here’s my updated to-do list. It has changed to become more focused. Some items taken out and new added. (Re-prioritized next-steps for the development of the plugin)
1. Remove front-end shortcode feature; instead move it to a dashboard area where an admin can view the stat(s). The reason is that the user of this plugin is envisioned to be the WordPress site admin and not a site visitor.
2. More clearly define the purpose of the plugin and how to use it. Write these clearly into the readme of the plugin. start to get the plugin ready for submission to the WordPress plugin repository. (Use this codex article (and the pages it links to) as a starting point guide: “Plugin Submission and Promotion” ( https://codex.wordpress.org..._and_Promotion )
3. Submit the plugin to the WordPress.org plugins repository.
4. In addition to the total site visitors that now can be displayed, while it’s moved to the admin area, let’s also display a per-month and per-day visit count breakdown.
5. In the proposed admin stats area, let’s display a list of which URIs the visitor visited. (this is already captured, now let’s display it to the admin)
That’s what I’ve done and what I will do, to further develop the mzz-stat plugin.
Supportops.co podcast episode #96 – “Make Meetings Count” with guest Justin Seymour. ( http://supportops.co/96-make-meetings-count/ ) Near the beginning of the episode, Justin says something like: [as HelpScout customer support, it’s our job to ] ‘be present for the customers’.
I liked hearing this because it seems accurate.
I’ve been thinking how it’s not accurate to describe Software
Customer Support role as “helping the customers”, nor is it
accurate to describe it as ‘problem solving’. ( see
Support is for a Software Support and Development Engineer
Instead, I like this description of ‘being present for the customers’. Also I like “triaging customer issues” or “troubleshooting customer issues”.
What does this mean for me as a software support person? “being present for the customer”. describes “being”, not *doing*. So in other words as a support person the accurate description of my job is to just be there and have conversations with customers, direct them how to use our software. Tell the customer how they can well use our software.
Indeed it is as some have previously discussed — on the supportdriven.com supportdriven.slack.com chat — software customer support is like being a Hotel Concierge / Front-desk Role.
Edit: This post was previously published at: wieldlinux.com/2016-07-03-support-is-being-there.php
--- wieldlinux.com Driven Support Not Free How to get a “driven” Support job? (i.e. a Software Customer Support job in the attitude of the supportdriven.com community in 2015-2016 ) Maybe look for a company where the customers are valued and the role of support is empowered and valued. Conversely, Be scrutinizing if these are anywhere in the sales or marketing messages: Support is free or it comes with support or unlimited support Which might indicate a company-wide attitude. Edit: This post was previously published at: wieldlinux.com/2016-07-02-driven-support-not-free.php --- On Software Development and Support Engineer Pay Rate How can a Software Development and Support Engineer attain and maintain a high pay rate? I see this is as a great challenge; a high rate of pay is something: -not easy to want, -not easy to define, -not easy to talk about (taboo), -not easy to understand how to get, -not easy to get or to maintain. – Wanted First, I have to get past the first step. A Software Development and Support Engineer has to want it. Drop it like it’s hot. Do it. Want it because attaining a high pay rate will make a Software Development and Support Engineer’s career and life better, and the act of attaining a high pay rate, in and of itself, won’t adversely affect those others around the Software Development and Support Engineer. Even though none of these things are easy, a high pay rate needs to be: -wanted -defined, -talked about, -understood-how-to-get, -gotten and maintained. – Defined In this context, pay isn’t a one-way transaction. It’s not just given by the employer. It’s also not just taken by the employee. It rather is offered and accepted. It’s a relationship, for example in the way that a friendship is a friendship. Pay is somewhat out of one’s control and depends on the actions of others. High pay rate involves offering by the employer(s) and acceptance by the employee(s), as part of an ongoing relationship. However it can also be defined in concrete, essential terms as a quantifiable dollar amount being passed from the employer to the employee. If as a Software Development and Support Engineer, getting a high pay rate is somewhat out of my control, then how to proceed? How to gain understanding of how to get it? – Talked about I posit the next step is to talk about it with others. Same as with anything; if one doesn’t understand how to do something, one should talk with others to figure out how to do it. Talk with others to understand how to get a high rate of pay. Why is this hard though? Because “people are funny about money”. There exists an American cultural taboo about talking openly with others about pay rate, salary and money, that is still at large today. All the same, the next step is to talk about it. I’m gonna be discreet in starting conversations. I’m not going to further bother those who indicate they aren’t open to talking about it. At the same time, I’m going to be discreet about my personal finances too (It’s not necessary to share personal financial figures and details– if the conversation gets uncomfortable for me then I’m going to calmly and politely stop the conversation at that point.) Some professionals will be open to talking about pay rates with a Software Development and Support Engineer. I can talk with them about it. – Understood-how-to-get In short, my way will be to regularly talk with colleagues (with other professional people) about what’s a professional pay rate, and about how to get a professional pay rate. The purpose of this talking will be to continually learn and understand what is a professional high pay rate is, and to continually learn and understand how to get such a pay rate. By iterating this type of conversation with professionals ongoing, what I’ll be doing is starting to define the quantifiable dollar amount of my desired pay rate. By continuing such conversations with colleagues, I’ll be continuing to define the quantifiable dollar amount of my desired pay rate. What’s next? Getting and maintaining a high rate of pay. I’ll say it straight out– I haven’t yet figured out how to do this. – Gotten and maintained. I think attaining it will involve me to regularly and periodically asking for the pay rate. Asking for it from a person who has the power to give it to me, that is. I think maintaining it will involve maintaining a high degree of professionalism and acting like an entrepreneur. But I’m still figuring this part out. Summary To summarize, as a Software Development and Support Engineer, I need to want a high rate of pay, realize it’s a relationship with a dollar amount attached to it, discreetly & regularly talk about it with others, and ask for it. I posit these actions and habits are what a Software Development and Support Engineer should do to try to attain a high rate of pay, and thus are what I should do to get a high rate of pay. Going forward, I’ll need to remember that even with any actions and habits, a high salary is somewhat out of my control, therefore I’ll still need to be persistent, be patient, and iterate. As a Software Development and Support Engineer, I don’t know how to attain and maintain a high pay rate. Although I don’t know how to do so, and although I will not be able to do it alone, I can want it, define it, talk about it, think about how to get it, try to get it, and (, if gotten,) try to maintain it! Edit: This post was previously published at: wieldlinux.com/2016-07-01-career-remix-performance-salary.php --- wieldlinux.com Communicate with the Customer Once the boss that the Software Customer Support boss reports to told the whole support team to: “…communicate with the customer even if we don’t have an answer and even if we don’t have good news…” So that brings up the question, is it the job of Support Engineer to “communicate with the customer”, period? Is that the core of the job– to communicate with the customer? Edit: This post was previously published at: wieldlinux.com/2016-06-30-communicate-with-the-customer.php --- wieldlinux.com For a Software Developer When Overwhelmed by Urgent Requests Actionable ways To Overcome the Feeling of Powerlessness True story — I get to the office and check my messages. I see a message from a customer who asks me to call them “first thing this morning”. At that moment my phone rings — it’s my boss who tells me to call that same customer. Before I checked my message and got that call, I had another important project on my mind that I had been wanting to do this morning. How to not feel overwhelmed and powerless in this situation? Here are some actionable ways. 1.) Immediately, before doing anything else, before calling the customer, take a few seconds to create a note of the “urgent” new case and move the case to the current date/time on my calendar. This way I feel that it’s me who is deciding to make it important; me who is moving my calendar and me who is actively deciding to make room on my calendar to make this new case happen right now. This is self empowerment. 2.) Realize that after I make the call and address the “urgent” new case, I’m going to be able to add the call-log-note related to this new urgent case to my “I done this” list after I make the call. Then I’ll be recording my work and getting deserved credit for my effort. 3.) Blog about it. I can do this by first making a quick note to write a blog post about the firefighting event. Then I can follow up and actually write the blog post and publish it to my blog (obfuscating any/all private information of course). This is empowering. Why? Because it allows me to make a record and take ownership of my effort on this case. I could take this one step further and during my next performance review or next job application, I can reference the material from this blog post as an example of my responsiveness and high performance. 4.) I can honestly look at my current top priorities (calendar/to-do) and quickly determine whether this new “urgent” request is *really* more important than my existing top prioirities. If it is more important, then I can actively agree that it is more important, which means that I took the initiative to review it and it was me who made the decision to make this case top priority, and go ahead and confidently address the urgent issue. If the new “urgent” issue actually falls third or fourth on my current list of existing top priorities, then conversely I can actively disagree that it is more important, which means I took the initiative to review it and it is me who made the correct decision that this case is third or fourth priority. I can go ahead and tell my boss that because of this more important case that it’s more benefit to the company to do the other cases first, then confidently put this new “urgent” issue in third or fourth place and do the other two more important ones first. Thus in this way I am confident, stress-free, comfortable, and retain feeling of power, and I do right by my colleagues to help the priority cases first. Are these four ways-of-dealing going to be enough to lessen my feeling of powerless-ness? What other ways can I take control of the situation, to keep stress low, and to make this type of firefighting be a daily sustainable activity? Edit: This post was previously published at: wieldlinux.com/2016-06-29-urgent-cases-powerless-engineer.php --- wieldlinux.com 35-Year-old Developer Learns To Bullshit Note: I wrote this some months ago. Shout out to supportdriven.com slack chat community for motivating me to write more during the blog #challenge. Today I turn 35. That’s not the point of this blog post, but it puts this blog post in perspective. The point is that as a 35-year-old Software Development and Support Engineer, I don’t know how to bullshit, but am now learning about it. I don’t know how to recognize bullshit. But I’m learning. Here’s what I’ve learned. A Software Development and Support Engineer is being bullshitted when the other person talks a lot but doesn’t answer the Software Development and Support Engineer’s question. There are other forms of bullshit too but this pattern particularly comes to mind. On a high level what it comes down to is, spending effort on something unimportant is bullshitting. In that sense I can bullshit myself too — if I spend too long trying to do some unimportant task. But between two people, it can take the form of one person wasting the other person’s time by purposely saying something misleading to them. In professional software engineering setting, between two people it can also take the form of Person A talking at length about something non-work-related like a hobby or like their personal life, *and*/*or* Person B listening to be polite. I’m learning how to recognize bullshit, bullshitters, when I’m being bullshitted, and when someone’s bullshitting me. I truly believe that by 10 years old, many people were expert bullshitters. I think that by some time in their teens or twenties, most people can bullshit and/or recognize bullshit. Furthermore by that age, most people assume that everyone else can also bullshit. Thus by getting older than that, and still being bad at bullshitting, there’s a sort of double-tough barrier to cross. For me to a large extent what I’ve done over the past two or so decades, is that when a person bullshitted me I would tend to not my head, smile, and then from then on avoid that person. From my point of view, it alienated me from a person when I realized that they had bullshitted me — I treated it as them lying to me, and I took it very personally, didn’t bring it up to them (didn’t confront them), internalized it, and tended to avoid conversations with that person from then on. Where has this gotten me? To be honest, now looking back on it, it’s alienated me from a lot of people. Looking back, but more recently, this is what I was trying to figure out in this previous blog post “For an IT professional it’s a Skill to get an Answer” ( http://wieldlinux.com/2014-12-17-IT-professional-skill-answer.php ). In that post in hindsight I was writing that as a Software Development and Support Engineer it is important to realize when someone’s bullshitting me. However. This blog post is not supposed to be *all* a rant. Moving on. I’m moving forward and getting better at bullshitting later-in-life. In fact I will be as bold as to say that without knowing how to bullshit, a Software Development and Support Engineer won’t be able to do their job! It’s that important. Every day, every conversation, every message exchanged, needs to be quickly analyzed for what level of bullshit it contains. If the bullshit gets in the way of a Software Development and Support Engineer’s important goal, then it must be addressed and either worked through, or else worked around. Where to go from here? As a Software Development and Support Engineer, once I get good at identifying when someone is bullshitting me, the next step will be to call the person out. When the bullshit gets in the way of my goal I need to every time call the person out — I need to every time confront them and let them know that I’m going to treat their bullshit response as bullshit, and adjust my actions accordingly to continue towards my goal. Where to go from here in terms of being alienated or not-being-alienated? Looking back in hindsight, now I realize that some degree of bullshit is normal, and the normal thing to do is to evaluate the degree of bullshit vs. the level of importance of the goal that is being impacted/hindered by the bullshit, and then either let it go or confront it *but (and indeed this helps with this) don’t let it negatively affect* my relationship with the other person. Don’t take it personally when it’s not. Indeed, it turns out that when used with each other between two experienced bullshitters, some bullshit is an effective tool to soften conversations and as a “meta” (alternate/indirect) way of communicating what’s important vs. what’s not important. What’s a high-level, overall conclusion here? For a Software Development and Support Engineer, no matter what point in one’s life one learns to recognize and properly react to being-bullshitted, knowing how to bullshit is a valuable skill. ( This post is somewhat of a follow-up on my previous post “As a Software Support and Development Engineer I am Bullshitted” (http://wieldlinux.com/2016-05-18-software-engineer-being-bullshitted.php) ) Edit: This post was previously published at: wieldlinux.com/2016-06-28-engineer-35-learning-bullshit.php --- wieldlinux.com How to React to Possible Bullshitting Situation and Options to Reply If I feel I’m being bullshitted, then I might want to quickly analyze (try and figure out), and do, the following things: – Is the person asking me something? (or for something?) – Is the person telling me something? (or to do something?) – Is the person fishing for information? For example they are neither asking nor telling me something — they just say a bunch of bullshit that doesn’t make sense and then pause and wait for a response. This could indicate the person isn’t trying to tell me anything at all but rather is trying to get me to tell them some information. In this case it’s likely important to the person that *I volunteer the information to them*, as opposed to them having to ask me for the information directly. In this case perhaps the person for whatever reason wants to retain the position of power in the conversation, but still wants to get information from me. – Is the person trying to indirectly/politely say “no” to something? – Try and figure out by the overall feel, context, tone and types of words that they are using, what their general meaning is. Ignore some of the details that don’t line up with their overall message. Even if their words are indirect or don’t clearly express a complete idea, their communication might, when taken as a whole, point to what the person is getting at. – Rephrase the person’s words back to them in a direct, clear, grammatically-complete sentence, and then ask them if that’s what they meant. – If the person is asking a yes/no question, and the answer won’t be yes or no, then rephrase the person’s question into a non-yes-or-no question, then reply to that non-yes-or-no question, then ask whether that answers their question. Edit: This post was previously published at: wieldlinux.com/2016-06-27-bullshit-determine-more-information.php --- wieldlinux.com Software Support and Development Engineer Techniques to Only do Important Tasks and Not Do Bullshit Tasks For every task in my calendar, before I do it and periodically while working on it, use *feeling* (emotion) to determine whether to keep working on the task or to break from it. Before and periodically, recall *why* this task is important (the reason for doing it –the overall goal of it). Then do this. If I feel this is what I should be working on, and I can remember why I’m working on it, then do it– keep doing it and get it done fast! If I either feel this isn’t what I should be working on, or I can’t remember why I’m working on it, then do the following. Ask the next-closest stakeholder to remind me why this is important. If the other stakeholder replies its not important, or if the other stakeholder doesn’t reply, (or if there is no other stakeholder,) then drop the task! Drop it like it’s hot! (permanently/immediately drop it off my calendar/ list, and don’t worry — if the task really is/was important then it will come up again and can again be re-added to my calendar/list) Edit: This post was previously published at: wieldlinux.com/2016-06-26-developer-no-bullshit-tasks.php --- wieldlinux.com As a Software Development and Support Engineer Failing and Succeeding I’m going to focus on activily failing better. Failing earlier and more often. As a Software Development and Support Engineer I’ve had a fear of failing that’s so bad that it’s that so-called “self-fulfilling prophecy” that results in me failing. Looking back on a few cases of this, I now see in hindsight that it’s gone like this: I get a Software Support and Development Engineer task in front of me. It might be a task of “medium” difficulty, which to complete will take back-and forth with other people, over multiple days’ time, and some personal effort. Then I freeze and just do nothing because I’m scared that I’ll fail. What is the result? Of course because I did nothing, I fail. Self-fulfilling prophecy. I’m going to try to improve my failing process. First, in the first hour, within the first two minutes of me knowing about the project, I will estimate whether I can do the project, figure out that I can’t, and tell the stakeholders within the first hour that I’m not going to be able to do this project because X. (X being for example because other projects, full calendar, I lack required Y Access or I lack necessary Z Power). In this way I’ll be failing to do the project, in a way that is better than failing-by-doing-nothing. Second, I’ll make an attempt to complete one part, iteration, or try at the project, for one hour, then stop, and consider how far done is it? Is it done but missing critical functional elements, and so not done? Or is only done one part of four, and so not done? (Since it really is a medium project, it will be one of these two) Then I’ll tell the stakeholders that I completed one attempt and failed. In this way I’ll be failing to do the project, but in a way that is better than failing-by-doing nothing. In either of the above, is communicating my progress to the stakeholders in any case, even when the progress is news-of-failure. In fact, taking it a step further, I’ll communicate every single project of mine as a failure *until the moment that it’s done* at which time I’ll then communicate it as a success. In other words I’m proposing an “under-promise, over-deliver” method. A key to this though is that I need to A. attempt to complete the project (as opposed to doing nothing) and B. do it with a light heart — with gusto and optimism (as opposed to doing it with a fear of failing) I know that I’ll find that, compared to the old failing-through-fear-and-inactivity, is this type of actively-often-failing will be magnitudes better. In summary, I’ll get better at failing. In this way I’ll move towards succeeding. Edit: This post was previously published at: wieldlinux.com/2016-06-25-engineer-failing-and-succeeding.php --- http://wieldlinux.com/ What Support is for a Software Support and Development Engineer One time, my support colleague asked me ‘Can you help Customer X from “Company Y? They have a question about “How to do Z).” What my support colleague meant was “will you triage Customer X’s concern?”, and the immediate answer was simultaneously “yes” and “I don’t know” — yes I can talk to the customer and investigate their concern — but I don’t know yet until the end of the conversation whether I’ll have to say I can’t help them or whether I’ll be able to directly help them. 90% of support is telling a customer I don’t know, in other words not helping the customer, (maybe/usually with a period of deep investigating into the concern), and the other 10% is doing something towards fixing their concern like reporting a bug, giving a refund or answering a direct question. It’s beneficial for a support person to realize this, because if one goes in thinking of one’s support job as “helping people” or “answering people’s questions” or “making the solution work for the customer”, that is setting up for anxiety and failure. It might be more accurately described as support is communicating with the customer about both what my company’s solution can do and what my company’s solution can’t do. Moving on. For a Software Development and Support Engineer, support is always unique and is never the same person with the same issue. Support is never the same issue — it’s a unique person with their own question every time. So then why are they treated as all being “Support”? The answer is that support is largely a triage channel. The job is to triage and send the bulk of the questions to other departments (sales, engineering, etc.) or back to the customer — or to answer a quick 2-minute question. Now once one realizes that support is triaging large numbers of unique questions, and sending them to the appropriate place, that is great; one can proceed to focus on doing that, and doing it well. Something else about support. Any communication from every customer could be considered support and triaged by support — support is equipped to begin the conversation supporting anyone with any issue. Furthermore, salespeople, executives, success people, professional services support people, and engineers all, at times, support customers. But for these communications, they are not support conversations, and for these roles their support is not customer support. Why? Because support is separating post sales customer requests from other customer requests, based solely on that fact. (The fact that the customer is post-sales — they already bought the software) The people in non-support roles don’t log their conversations into the support case ticket system. So in other words, support is only limited to: 1.) Cases that are post-sales, and 2.) Cases that came in through the “support” channel. To recap, “Support” is the fraction of a company’s overall customer support effort that is a one-way triage inbox for post-sales customer requests. After the “support” request hits the inbox it goes through initial triage where about 90% of the requests are forwarded or denied as “the reason it’s no is because ___”, and about 10% of the requests are directly fixed or addressed. Support is communicating with the customer about both what my company’s solution can do and what my company’s solution can’t do. Edit: This post was previously published at: wieldlinux.com/2016-06-24-what-customer-support-is.php --- wieldlinux.com Listening to Carrie Dils officehours.fm podcast “A Dynamik Change to a Pricing Model, Episode 79” ( http://officehours.fm/podcast/79-2/ ) They start talking about support. and licensing, and Help Scout. and support costs. and more customer support stuff. Edit: This post was previously published at: wieldlinux.com/2016-06-23-officehours-talking-customer-support.php --- wieldlinux.com As a Software Development and Support Engineer I need to do fewer things and do them quicker. That is all. —— Why is this blog post two sentences? http://two.sentenc.es (but for blog-writing) Edit: This post was previously published at: wieldlinux.com/2016-06-22-engineer-fewer-things-quicker.php --- wieldlinux.com Two-way Proactive Synchronous Support – Merging Marketing and Sales and Support – Customer Success or Customer Experience The support part of the role of a Software Support and Development Engineer traditionally has been reactive. Tech support or customer support has been long established as a cost center that reacts-to, resolves, and answers these things: customer questions, issues, concerns, and complaints. Do I call my building maintenance person to ask how they are today? No, I tend to only call them when my plumbing has a problem, or my heating, or when something is wrong or broken or needs fixing. Do I call support when my software isn’t broken? No. This presents a problem. It means that usually, by the time the customer picks up the phone (or writes the email), the customer at that point already is concerned, unhappy, unimpressed, or confused. The problem is the customer, and the Customer Support person, is constantly faced with this negative energy. It’s not balanced. It creates an unbalanced life for the customer and for the customer support person. The customer has to call a general number (or a general email address) and ask a stranger for help. This means that the first time the customer and the support person meet, it is over a problem. How terrible is that? This problem is in part caused by the traditional role of Marketing developing a relationship with the customer then passing the customer to sales, then sales developing a relationship with the customer then passing the customer to support. How to fix this? What if support was two-way, proactive or synchronous. What does this mean? It means the support person periodically calls or emails the customer and asks how things are. “Hi Jane, I can’t believe 100 days have again passed! It’s me, John from ACME, and it’s time for my regular 100-day call to ask you how our solution’s behaving for you?” Wow! Amazing — John from ACME has the support strength, foresight, caring and attentiveness to call the customer and introduce himself(or again say hi if they already met 100 days before). John has in effect performed a bit of marketing and sales, by contacting the customer and checking in. This is what nowadays people call Customer Experience or Customer Success. John is a Customer Success Engineer. What happened here? Well John and Jane are meeting for the first time when Jane likely wasn’t stewing over a problem. The degree of negative energy will likely be much less. Now that they know each other exist and know each other’s names, they will be able to know who to call *if* there *does* ever arise a problem. Also it’s balanced for both people. Another way to fix this? Welcome the customer to call in any time to talk about the software, even when there’s not a problem. Traditionally an exception has been that some people give their building maintenance person a baked goods or a bonus money at new year’s day. Also, some companies send a holiday card to their customers on New Year’s day to see how things are going and check up on them and say thanks. And that is something that some companies traditionally have done. The marketing or sales department would have done that. To summarize, traditional Software Support’s problem of the first support contact being over a problem is caused by marketing and sales being separate from support, and the answer can be merging marketing with sales and with support. The answer can be the support person or the customer reaching out ahead of time to establish a relationship in the beginning, in the manner done nowadays by Customer Success or Customer Experience pros. Edit: This post was previously published at: wieldlinux.com/2016-06-19-success-merges-marketing-support.php --- wieldlinux.com As A Software Development and Support Engineer Balancing Consistency with Flexibility As a Software Support and Development Engineer I must lose consistency and gain flexibility, until I reach a balance. ‘Consistency is the hobgoblin of a small mind’ (quoted from memory – from on the OurSQL Podcast, one of the very early episodes while there was just the founding host Sheeri and there was a “quote of the day’.) I’ve heard people describe this in other people as, “(He) has demons”. How can I tone down the consistency just a bit, not value consistency for consistency’s sake, and become more flexible? As the Trailer Park Boys might say, how can I ‘self smart’ myself — ‘from nature’? If I can tend away from extreme consistency, and become more flexible in the way I think for high-level aspects of my suite of professional behavior, it will benefit my career greatly. I heard it quoted elsewhere that ‘the definition of insanity is doing the same thing and expecting a different outcome’, which is along these same lines. There can be strength in flexibility. Consistency can be a strength but is perhaps at direct odds with flexibility which is also strength. Therefore they must be balanced. I need to lose consistency and gain flexibility. In conclusion, as a Software Support and Development Engineer I must lose consistency and gain flexibility, until I reach a balance. Edit: This post was previously published at: wieldlinux.com/2016-06-10-engineer-balance-consistency-flexibility.php --- wieldlinux.com The Goal is to Keep the Customer Using the Software Solution This realization hit me strong after the supportdriven.slack.com conversation on about 2015-10-09, where one person wrote that they focused on a strategy of (how many customers requesting)+(whether the customer will stop using)+(how much money the combined customers are paying), and reported this to their boss as a way to leverage a feature request to be added/included. For a Software Support Engineer (SSE) here’s a goal. The goal is to get each customer to keep using the solution. In other words, my goal as a Software Support Engineer is to message with the customer so their concern is addressed in such a way that they are more likely to keep using my company’s solution and really what this means is that they renew their license subscription. This is simple, and direct, and core to my mission as a Software Support Engineer. Sometimes Software Support Engineers and their colleagues say things like A.) the SSE’s goal is to “keep the customers happy” or B.) the SSE’s goal is to “help the customers”. Then the SSE is stressing out about those cases where the customer isn’t happy and where they don’t seem to be helping the customer. Either of these goals is less effective because they will lead to the SSE in some cases being set up for failure — those cases when when the SSE can’t help the customer, or when the SSE can’t make the customer happy. The first goal — acting according to what is most likely to keep the customer using the solution — is more effective. Often there’s a scenario where an SSE can’t help the customer, and also can’t make the customer happy, but that doesn’t matter because it’s a scenario where the customer will keep using the solution. The SSE and their colleagues will be more effective when they help the customer and keep the customer happy, but only in the context of them using the SSE’s company’s solution. Sometimes SSEs and their colleagues say things like 1. an SSE’s goal is to make the technology work for the customer, and also 2. an SSE’s goal is to act in such a way that it will benefit the SSE’s company’s shareholders/stockholders. These are good, and could be taken as they are, or, could be made even more concise and focused by combining them. There is a more concise goal that combines keeping the customer happy and to helping them keeping using my company’s solution. The more concise goal is act in such a way facilitates the customer renewing their license subscription. But remember, another take-away from the strategies above is what a SSE can stop doing. They can stop doing these: (I.) If if an SSE truly can’t help the customer in the given situation, then the SSE can stop trying to help them. (II.) If the customer is asking for something that they want but without it they will keep using the app, then the SSE can stop trying to help them. In summary, an SSE will do well to focus on those cases where both the SSE can help the customer, and the SSE helping the customer results in the customer keeping using the solution. Edit: This post was previously published at: wieldlinux.com/2016-06-06-engineer-keep-customer-using.php --- wieldlinux.com For a Software Development and Support Engineer Finances are Important For a Software Development and Support Engineer finances are important. Reviewing finances, personal accounting, and balancing one’s checkbook is important for a Software Development and Support Engineer. Isn’t this as important to the next person as it is to a Software Development and Support Engineer? Yes, it is important for everyone, and also for a Software Development and Support Engineer too. So why is it important for us? Its important because finances are a measurer, and an enabler, of high performance and high pay. As a Software Development and Support Engineer if one isn’t comfortable with the state of one’s finances then it affects one’s job and one’s job affects it. If one looks and sees that one’s frugal and is following a financially sustainable plan, but that one’s not earning enough, then that could be an indicator either that one’s not in a challenging role that commands a high pay, or that one’s company’s not paying enough. In ths case, one thing one can do is, while keeping performing high as always, ask for a raise, or look for a better opportunity. In either case, the point is that one should be in, or looking for, a role with a company that both demands high performance and pays well! If one’s overspending or generating debt without a plan to pay it off, or without the income to pay it off, then that will negatively affect one’s Software Development and Support Engineer job performance and negatively affect one’s career. Daily/Weekly/Monthly looking at one’s finances will help one see whether one’s overspending and then one will know it and then one will be able to start to address it. If a Software Development and Support Engineer looks and sees healthy finances, then great! That means one may not need to seek career changes; they can then continue to focus on maintaining a/that high level of performance. Or if one’s all set financially then go volunteer to contribute development and support engineering efforts to an open source project, or whatever one wants to build one’s career. Or go back and get a (second) software engineering degree. Or a finance/accounting degree 😉 If one’s checkbook is balanced and one’s finances are healthy, then that gives a Software Development and Support Engineer more career choices, not fewer career choices. Here’s the summary of this pep-talk; it’s important for a Software Development and Support Engineer to look at one’s finances regularly, and look at them often. What one sees there can be an indicator of a high-achieving career and can be an enabler of a high-achieving career. So go! Go out there and sit down and balance that checkbook, fellow Software Development and Support Engineers, and let’s figure out whether our finances are in order. Then find out what we need to do to get them in order, and do it. It’ll make us better Software Development and Support Engineers. Edit: This post was previously published at: wieldlinux.com/2016-06-04-software-engineer-finances-important.php --- There is some Inertia in the time Between When A Software Support Engineer Works on a Case and When a Software Support Engineer Logs a Case There is some inertia in the time between when a Software Support Engineer works on a case and when a Software Support Engineer logs the case notes for that case. A question that arises in this scenario is, at what point is the Software Support Engineer’s task complete? The correct answer is that the progressing of the case and the logging of the case notes is all one task, and the task isn’t complete until both parts have been done. Furthermore the two parts are insepearable– in other words, I’m positing that until both parts are complete, *no work has been performed* This may sound counterintuitive! But in a system where management gets 100% of their information about a Support Engineer performance through the logged case notes, unless the notes are logged, it actually equates to the Support Engineer not having performed any work. By the counter-token, if notes are logged without having performed a task — if notes are logged without having progressed a software support case — then the Support Engineer also is in a situation where *no work has been performed*. The inertia that I’m talking about happens at that moment where the case has been progressed between the Software Support Engineer and the client, for example a half-hour-long conference call where the case was progressed. At this moment someone who doesn’t know better might think that work has been done. However that’s not so– the case notes must be logged. Consider this inertia. In other words, if one doesn’t know about this inertia and its effects, then they might not be doing their job. In fact, I might consider this the “third element”, or component, of performing customer software support engineering case work — the first is progressing the case with the customer, the second is overcoming the inertia to push through to complete the case notes, and the third element/component is the actual act of completing the case notes. In software customer support engineering, this 1-2-3 combo must be bundled together and done as a unit, every single time a case is handled, in order for work to really have been performed. Edit: This post was previously published at: wieldlinux.com/2016-06-01-support-progress-logs-inertia.php --- wieldlinux.com On a Software Development and Support Engineer Owning Recurring Tasks I saw a social-professional pattern where the boss tells the employee to do a recurring task, with no end date/time and then as time goes by also the boss doesn’t actively have a further conversation with the employee to review how the task is being handled. In other words the manager gives a standing order to the employee and then forgets it. For example the boss tells the employee to do a daily errand every day. This could add up — if the boss gives 100 standing orders to the employee over the course of the year, then that is 100 recurring tasks that are expected to be done. I say there’s a good way and a bad way for an employee to handle being assigned a thankless recurring task. This is outside of the employee saying that no, they won’t take on the task. I say a good way is for the employee to do the tasks but also check back periodically telling the boss how its going with that. I say a bad way is for the employee to do the tasks and never periodically remind the boss how its going with that. In the good, checking back way, one scenario could go like this: The employee takes on numerous tasks throughout the year, and also remembers to check back with the boss on each of them periodically (like once a quarter) to ask how things are going with them? (whether they still need to be done?, are they being done right?) And then the years go by and each quarter, the employee touches base with the boss on each of the tasks and how its going. The employee’s schedule is filled with the tasks as long as the boss still agrees they are important, and both the boss and the employee continually realize that the employee is adding value by doing these tasks. Since the employee is spending great effort and the boss is periodically recognizing them for it, for the employee it can promote professional acknowledgement, sustainability, recognition, the boss recognizing the employee’s good performance, reviewing of tasks to cull out unneeded ones and leaving only higher-priority value-adding tasks. In the bad, never periodically checking back way, the same scenario could go like this: The employee takes on numerous tasks throughout the year, and doesn’t check back with the boss on any of them to ask how things are going with them? ( whether they still need to be done?, are they being done right?) And then quarters and/or years go by and not another word is spoken on the subject. If, for each of those tasks, no conversation is had regarding the ongoing handling of the tasks, then a situation develops where the employee’s schedule is filled with tasks, and they’re the only person who’s attending to the tasks. Since the employee is spending great effort and not being recognized, it can lead to resentment, burn-out, the boss not recognizing the employee’s effort, and tasks still being done that actually no longer need to be done. This scenario, is above split into two extreme outcomes. However, this does happen on some scale. It would be an excellent boss who gives a standing order and then themselves remembers to check back each quarter to ask the employee how its going. I think often what the boss means when they give a standing order with no end date, is “Do task “x” every day, and check back with me quarterly to review the handling of task “x”.” *but* the boss doesn’t actually *say* the last: “and check back with me quarterly…” part. In any case, in order to as the employee take ownership and be professional, its the job of the employee to check in with the boss periodically to review the state of the standing task. Here’s where some smarts can come in. The employee can realize that even though no end date was specified and the boss doesn’t initiate a review, *the employee* can periodically check in, and can ask for an end date. Say the employee does a daily recurring task reliably for 90 days and no one says anything — it’s taken for granted that “the employee does that task” or “the employee does that task because they like to do that task” or “the employee does that task because they are good at doing that task”. Let’s not have any of these things be taken for granted — let’s talk about it periodically. If once a quarter, the employee reminds the boss “hey, now that I’ve been doing this task every day for 90 days, how have I done with that? I just wanted to confirm that doing-the-task should still continue to be done the same way, or ask whether it should be done differently”. There are some benefits for the employee here, and some for the boss. (a “win-win”! scenario) One is that the employee has taken ownership of the task. The boss initiated the task, but now the employee’s the one initiating the continuation of the task. It shows initiative, responsibility and professionalism. Two is that it’s a reminder to the boss that the task isn’t doing itself — the employee is doing it and is thinking about it regularly. Three is that sometimes new people come on board. And if the employee is busy doing recurring tasks and no one’s talking about it, then people will think “the employee does that task because they are good at it and they like it”. And so maybe the new person will have a better chance to get assigned that new challenging project that is seen as adding value to the bottom line, and the old employee will be more likely to be the one who stays in the role of thankless-task-doer. When really if a company promotes from within then the old employee should have a way to move from the less challenging role into a more challenging role. And of course if this new person comes in and new-project-assignment starts to happen when the employee hasn’t been checking in quarterly/regularly, and the employee then says “hey how about I get the new challenging project?”, then the chance is that it’ll be seen more as they want to leverage themselves in front of the new person, but conversely if this starts to happen when the employee has been checking in quarterly, and the employee says “hey, since I’ve been doing a good job with the task-doing — what are the chances that I can apply the same pride and ownership to the new challenging project?” Four is that the reason for the employee to check in on a recurring-task status regularly on a by-the-calendar schedule, like quarterly on the fifteenth of the first quarter of the month or whatever arbitrary recurring date makes sense, as opposed to whenever they feel like it, is that it shows that its a routine check-in — the employee is merely checking in in a responsible way — removing any doubt that the employee just had a bad day and didn’t feel like doing the task and is checking in to try to get out of doing the task. In summary, bosses ask employees to do recurring tasks. (Yes this includes us Software Development and Support Engineers) A good way for the employee to handle this is to take the ownership of the task, do a good job of it, and regularly & periodically check in with the boss regarding this task. Edit: This post was previously published at: wieldlinux.com/2016-05-28-engineer-Owning-recurring-tasks.php --- wieldlinux.com Software Support and Development Engineer ten year goals: Colleagues that challenge me Salary that sustains my lifestyle Working with people that I fit in the culture ——————————————– Q: Why is this blog post three sentences or less? A: http://three.sentenc.es (but for blogging) Edit: This post was previously published at: wieldlinux.com/2016-05-25-career-ten-year-goals.php
As a Software Development and Support Engineer (SDASE), I’m bullshitted.
There’s a social economic pattern that applies to being a SDASE, that I want to share here.
The pattern is that of a SDASE being bullshitted(*) by the SDASE’s colleague. For example this pattern may be performed by the colleague in an attempt to see whether the SDASE knows they’re being bullshitted.
Once a SDASE is aware that this pattern is commonly practiced by their colleague, they can act properly and call the colleague out for bullshitting, confront their colleague for testing them, or call the colleague out for being incompetent or unknowledgeable.
Why blog about this? Isn’t this something most people learn about before age ten? I think that one’s never too old to bullshit, be bullshitted, to learn/recognize for the first time that being bullshitted is a “thing”, or to revisit the concept. Some things, some people learn when they’re a child, and other people don’t learn the same lesson until well into adulthood.
This raises some questions. How do I recognize bullshit? Looking back on my life, which were the times when someone was bullshitting me and I didn’t know it? If I didn’t think it was bullshit, then what did I think was happening?
Reflecting back on my life, there have been numerous times when a colleague has said something to me that directly contradicts something that I know we both know. Without suspecting bullshit, in the past I would have reacted one of two ways: A., I felt that the colleague was unknowledgeable or incompetent, or B., I was confused why they would say that when I had thought they knew otherwise. Not suspecting bullshit, I’d need to ask for clarification.
Going forward, as a SDASE now that I know that occasionally, as a routine test, people will bullshit me, what I’ll do is point out to them that they’re bullshitting me — point out to them that I know that they’re testing me — and then get on with what matters.
There is a beauty in bullshit though. That is the person being bullshitted only has one real option — to call the bullshitter out on it. This is because whether or not its a test, the bullshittee, being a professional, should be correcting the bullshitter on the misinformation or on the discrepancy.
Another thing I’ve found is that looking back I can’t help but think of those times when someone had in the past bullshitted me, and I failed the test — failed to call them out. Thereupon they (the bullshiter) saw that I (the bullshittee) had failed their test. After they realized that I had been easily bullshitted, that I had failed their simple test, I can’t remember one of these colleagues/people calling me out for being easily-bullshitted.
That raises another thing about bullshitting. One can’t expect the colleague to take one aside later and say something like “Hey, by the way, this morning when I said that I was bullshitting you — I was testing you to see how you’d react.” Maybe because after the colleague sees the result of the test, there’s no added value in addressing the interaction any further.
In conclusion, I’ve noticed a social economic pattern that is a colleague bullshits a SDASE — tells a little lie to test how the engineer will react. As a Software Development and Support Engineer, now that I know that this kind of testing in some professional circles is a common practice, I’ll be able to react appropriately.
(*)being bullshitted: 1. When a colleague asks me a question to which they already know the answer, to see how I will respond, I am being bullshitted. 2. When a colleague makes an untrue statement and observes to see whether I will point out the falseness of the statement (see whether I will call bullshit on them), I am being bullshitted.
Edit: This post was previously published at: wieldlinux.com/2016-05-18-software-engineer-being-bullshitted.php
--- 2016-05-14 wieldlinux.com Thinking of Product-izing Software Support I’m thinking of product-izing software support by quantifying it in terms of the quantity of high-quality documentation + messages that I produce. ——————————————– Q: Why is this blog post three sentences or less? A: http://three.sentenc.es Edit: This post was previously published at: wieldlinux.com/2016-05-14-product-izing-software-support.php --- 2016-05-13 wieldlinux.com Adapting Two.sentenc.es to Blog Writing I heard of two.sentenc.es from the persona of Carolyn Kopprasch ( https://twitter.com/carokopp ) of supportops.co podcast fame. But I can’t bring myself to use it for email because I don’t truly believe that would be realistic — *However* I love the idea and will play with using the same concept *for writing blog posts*! ——————————————– Q: Why is this blog post three sentences or less? A: http://two.sentenc.es/ Edit: This post was previously published at: wieldlinux.com/2016-05-13-three-sentences-blog-posts.php --- 2016-05-12 wieldlinux.com Thoughts on Software Support and Development Engineer supporting a Product Supporting SaaS I’ve felt confusion about about what I’m supporting — is it a product or a service? The answer is that if its sold as a product then it is product and the sales, support, and customer must all treat it as such. I ask a SaaS salesperson what they are selling. They say they are selling a product. They sell the following products: “(A) solution” “(a) platform” “(an) experience”, “(an) access”. I do subscribe to the idea that people are willing to buy a product, not pay for a service. This view makes it smart to sell something as a product. When supporting something, it should be supported as it was sold, so therefore it should also be supported as a product. Making a comparison to food service. At my local premium coffee chain store I buy a coffee. But I’m really paying for the service of brewing, serving and selling me hot coffee in a cup and the polite service and attention. But in my mind I think I’m just buying “a coffee”. In other words I’m paying for the premium service but I think I’m paying for “a coffee” — a product. So with SaaS the customer in their mind is buying “a platform” but they are really paying for a delivery service and data hosting and service availability etc etc. Anyway I have to support what I, what my company, sells. If I sell the following “products”: “(A) solution” “(a) platform” “(an) experience”, “(an) access”, then I have to support these. Here’s where confusion can creep back in. None of the four above mentioned are a single thing that can be pointed to with one’s finger. SaaS is a system of networked software and hardware. So I need to support this system of networked software and hardware, of which I have direct access to only portions of it. I need to ask my DevOps colleagues for help to access the other portions of it for me, to fix it for me. Furthermore if my salesperson at any time advertises/sells my product as a service “…you don’t have to worry about infrastructure, we host everything in the cloud…”, then that plants the seed for the customer to later approach me to support the product as a service. Supporting an application that was installed from an install CD onto the customer’s own computer/server is different. I supported such a software, along with a printer and barcode scanner that I (my company) sold. More of the pieces were owned by the customer. The customer could only get updates by either us sending them a new CD or by downloading the installers from a download link that we sent them in an email. (no option for automatic download and update was available) It was clear that the customer owned the entire solution on premises. It was more clear that they were responsible for using, operating and supporting it themselves because they owned the entire solution– the hardware pieces and all of the software pieces (including database and server) were all on their own premises. Circling back again to Saas — I have supported SaaS. The idea comes in that I (my company) is seen as owning part of the solution. I (my company) control the service and the data and the database. If there is any connection trouble to the service or the data or the database, it appears to the user that they don’t own the solution. The instant they can’t access the service they realize a feeling that this isn’t a product that they own. What’s the bottom line? I need to support the solution as a product. As a solution. As a platform. I need to keep the “ownership” of the solution/product/platform *on the customer*. I can do my all to support the customer using this, the product/solution/platform that they own, but fundamentally I must support it as a product. Why? for my sanity. And my company is selling it that way. They bought it so they own it. For an instance of (a subscription to) SaaS that is sold as a product, then it is a product, and the sales, support, and customer must all treat it as such. Edit: This post was previously published at: wieldlinux.com/2016-05-12-support-software-as-product.php --- 2016-05-11 wieldlinux.com As a Software Support and Development Engineer How to Measure and Improve my Performance Here are some distillations of how to measure and improve my software-development-and-support engineer performance. In my previous post entitled: “As a Software Support and Development Engineer What I Do and What I Produce” ( http://wieldlinux.com/2015-10-03-what-I-do-produce.php ), I defined this: “… My primary service: – Transport messages across distance with another person. My primary goods-production: – Produce messages, instructions and documents. …” Now that I have defined what I do and what I produce, I can do neat things with that knowledge, such as start to define how to measure my performance as a professional Software Support and Development Engineer, and how to improve my performance as well. Here’s what I mean– how can I measure and improve my performance in terms of my service? * The frequency and timeliness of messages does matter. My performance can be measured/improved by the frequency and timeliness of my message-sending. * To improve my performance I must increase the frequency and maintain the timeliness of my message sending. * The quality (accuracy and beauty) of the messages, instructions and documents should be consistently excellent, and the quantity (the number) of the messages matters. My performance can be measured on the quantity of high-quality messages that I send. * To improve my performance I must increase the quantity of the high-quality messages that I send. The above are some distillations of how to measure and improve my software-development-and-support engineer performance. Edit: This post was previously published at: wieldlinux.com/2016-05-11-engineer-measure-improve-performance.php --- 2016-05-10 wieldlinux.com Contact a Person Not a Company — OR — A Feeling of Good Customer Service I am feeling that good customer service is this: As a customer, I contact a person instead of group/alias/company. So the contact page on the company web site, there are pictures and names of 1-3 people and their phone numbers. And I contact them for support instead of contacting the “support nubmer” and their email addresses are there. and I email their addresses. As a support person, I advertise for a customers to contact me as a person. Don’t contact a group/alias/company and end up talking with me. Instead contact me as a person who represents my company. In short, communciation for customer service/support, no matter its between a company and a person, should be between an individual company representative and the customer. That’s good customer service. Edit: This post was previously published at: wieldlinux.com/2016-05-10-contact-person-not-company.php --- 2016-05-09 wieldlinux.com Work productivity trick for a Software Support and Development Engineer. Work productivity trick for a Software Support and Development Engineer. This trick is designed to help me not to spend too long on one task, *and* also to get at least a minimum number of tasks completed each day. Make it my goal to, each half-hour on the half-hour, try to get one task done in the first 5 minutes of the half-hour. Of course half-hour-long chunks of time tend to roll into one another (after 30 minutes they do). So to plan for this and make this trick work, it’s also necessary to break at the twenty-minute-mark of each half-hour-long time block. The trick is this: for a person who tends to spend too long on one task, the trick to increasing productivity is actually to *take more frequent breaks*. And also to *more frequently start or continue working on tasks*. This breaking into half-hour-long-chunks method, in conjunction with my natural tendency to spend a long time on a task, will tend to result in me wasting less time, starting working on tasks more frequently, working on a greater number of different tasks, completing a greater number of tasks, and more frequently completing tasks. In other words, before this method, my day might have looked like this: … — *9:00am: – spend 60 minutes worrying that it’s going to be a waste of an hour to work on the task, and then start working on it, and then work on it straight for the remainder of the 60 minutes. (repeat, continue throughout the hours of the work day) , and now after implementing this method, my day looks more like this: … — * 9:00am: – spend the first five minutes working on a task. (and try to complete the task) * 9:20am: -take a break and step away physically from the work area. * 9:30am: – spend the first five minutes working on a task. (and try to complete the task) * 9:50am: -take a break and step away physically from the work area. (repeat, continue throughout the hours of the work day) — The result is that in the examples above, in the former I’ve only worked on one task in an hour’s time, and by the end haven’t yet completed it. In the latter example I’ve at least worked on two tasks. The difference is that I’ve likely completed two tasks with the latter method, and worst-case, I’ve at least progressed two tasks. Whereas with the former method, I likely haven’t completed even one task (because I don’t have a stop-and-step-away. and worst-case, I’ve only progressed one task. Edit: This post was previously published at: wieldlinux.com/2016-05-09-software-developer-productivity-trick.php --- 2016-05-06 wieldlinux.com A Dream to Productize Service Industry Starting with Software Support and Development Engineer Service I was distilling a previous blog post some more. (“As a Software Support and Development Engineer What I Do and What I Produce”, http://wieldlinux.com/2015-10-03-what-I-do-produce.php ) I finally got to define what I produce in terms of goods and services. In doing so I ended up thinking of the value, to a Software Support and Development Engineer, of being able to quantify the results of one’s work. A dream is that any service industry professional should be able to do the same. For example a delivery driver should be able to quantify their performance in terms of “Deliveries”. And they can from there sell their deliveries as a product, positing that their Deliveries are excellent quality, and that their deliveries are worth $xx. apiece, and to ask anyone and they’ll say that their deliveries are high quality and are worth $xx. apiece. But this post focuses on the same but for a Software Support and Development Engineer. A dream is that a Software Support and Development Engineer should be able to quantify in terms of number of messages produced. And posit that their messages are worth $xx apiece. So as a Software Support and Development Engineer I can say that my messages are excellent quality, and so they are worth this price of $xx apiece. This productizing — this treating the results of my work as goods — this gives us a bargaining tool to really express the value that we add to our company. The benefit is that it allows a Software Support and Development Engineer to know, talk about, and feel, how much value they add, and what our effort is worth. I feel like this should be called a dream, because this is not the way things are, and, there’s not a plan for this to become the way things are. Moving on. what’s the point? The point is, the dream is for all service pros to be able to quantify their perfomance by amount of goods produced and not by number of hours passed on the clock while they worked. Edit: This post was previously published at: wieldlinux.com/2016-05-06-productize-support-engineer-service.php --- 2016-05-05 wieldlinux.com Proposing a Strategy to Overcome Personal/Professional Workplace Conversation Dichotomy Here I propose a strategy designed to help me as a Software Development and Support Engineer learn to more quickly switch between personal and work personas, and to overcome my tendency to prefer personal conversations. When I tend to prefer personal conversations and avoid professional conversations in the workplace, my colleagues realize it and start to disengage with me as a professional. Which of course is murder to my (to anyone’s) career. I need a plan! And I’ve thought of one. To train myself to be more professional, I’ll enact a 30-day period where, at work, I ignore chitchat as if the other person didn’t say anything, and I instead reply with a work- related topic. Then depending on how it has gone, after the 30 days I can try to again start participating in chitchat. This strategy is designed to help me as a Software Development and Support Engineer to more easily switch into work mode, and to train myself away from preferring personal conversations. Edit: This post was previously published at: wieldlinux.com/2016-05-05-overcome-personal-professional-dichotomy.php --- wieldlinux.com For a Software Development and Support Engineer an Unplanned Benefit of Working on Pomodoros is that I Spend more time Talking with Colleagues I started working on pomodoros. I started to write about it here: http://wieldlinux.com/2016.php?2016-04-30#2016-04-30
wieldlinux.com/2016-04-30-local-calendar-pomodoros-productivity.phpI did it to improve productivity and clear my mind so that throughout the day I would be able to re-focus and thus stay focused, on what’s important. Every 30 minutes, I stop for two minutes to write a note of what I did, triage email and triage calendar. It has indeed improved my productivity as a Software Development and Support Engineer, but also it’s improved another aspect of my professionalism. Now I’ve changed to where I, here-and-there throughout the week, *end up spending a few more minutes talking with my colleagues* face-to-face in the office. Since I get up and stretch every half hour, and make a point to not sit down until at least 120 seconds later, I end up having nothing to do but listen to what my other colleagues next to me are talking about. As a result, I tend to stop and listen and ask what’s going on and start to participate in more brief conversations. As a Software Development and Support Engineer, I’ve found that a benefit of working on pomodoros is that I spend more time talking with colleagues. Edit: This post was previously published at: wieldlinux.com/2016-05-04-unplanned-benefit-of-pomodoros.php --- 2016-05-02 wieldlinux.com For a Software Support Engineer when At Work Always be Interviewing As a Software Support Engineer, when at work I should always be interviewing. What does this mean? I mean in order to propel my career forward, when talking to colleagues I should have the same attitude as if I am interviewing for the job. In other words, I should be focused on work and should always act with a professional attitude and my actions should be professional. There is a story that is spurring me on, to want to adopt this attitude. Upon returning from vacation, my great-grandboss (my supervisor’s boss’ boss) asked me ‘How was vacation? did you spend time with [your family]?’, and my reply was basically: “Uh, yeah. Uh, it was good.” However thinking back I should have replied “[insert great-grandboss’ name here], yes my PTO was good. I spent some time thinking over how to improve my productivity for the company upon my return.” In other words, when talking with colleagues and especially in this case talking with my boss’ boss’ boss, who is therefore my boss, I should always reply with a note about how I’m adding value to the company. This is no matter whether the conversation starts to steer to personal topics. I should make an acknowleding remark about the personal topic *but then end the sentence with something about work and company productivity* For some reason, and it may indeed be lack of personal professionalism, I tend to respond to personal comments at work with more personal comments. But my point here is that when at work I should always be interviewing– I should always reply to all comments with professional comments. Indeed thinking more on it now in hindsight, I see that my colleagues, sometimes purposely and sometimes inadvertently, test me in a way, by seeing how I reply to personal comments. And if I reply professionally then they think of me as professional but if I reply with personal comments then they think of me as unprofessional. And then over time based on my historical replies it’ll develop *even further* and I’ll either be thought of as That Professional Colleague, or thought of as That Unprofessional Colleague, depending on my answers. In conclusion, as a Software Support Engineer, when at work I should always be interviewing. Edit: This post was previously published at: wieldlinux.com/2016-05-02-engineer-always-be-interviewing.php --- 2016-05-01 wieldlinux.com The Benefits of the Calendar and Pomodoros System I used my calendar + pomodoros system. Its main benefit is that it turns all tasks into synchronous tasks. This system consists of 30-minute pomodoros where I break for (up to) 10 minutes each time. So I work at the next asynchronous task for at most 20 minutes, then break to breathe, stretch, write my get-it-done note, triage new emails, and check my calendar. The value-adding effect that this has is that it essentially turns my to-do list of asynchronous-tasks into a bunch of synchronous tasks! (asynchronous-task meaning a task that that needs to be done now/asap; a task that doesn’t necessarily have a deadline but that just has to get done “the sooner the better”.) For example a task could be replying/progressing/solving a customer software support case from the existing queue of cases. For another example is checking my email inbox and reading the new emails and triaging action-items to my calendar or to-do list. Why is this calendar + pomodoros system value-adding? Because as a Professional Software Development and Support Engineer, I need to do both sync tasks and async tasks, and turning async into sync lets me treat all as sync which simplifies my flow by an order of magnitude. So now I can check for calendar events each half-hour (a synchronous task that needs to be done every half hour by the clock), and at the same time check my email (which would otherwise be asynchronous because an email could come every minute or every 4 hours, and could be processed immediately if I wanted) To summarize, the main benefit of the calendar + pomodoros system that I’ve started using, is that it turns all tasks into synchronous tasks. Edit: This post was previously published at: wieldlinux.com/2016-05-01-synchronous-asynchronous-flow-calendar.php --- 2016-05-01 Productivity Idea for Software Support Technician As a Software Support Technician and Developer, for times when I need to quicken my focus and sharpen my response as a Software Support Technician. I am going to try this trick which will be to keep all to-do tasks in an external repository, like the service desk ticket system, and then load up only the one most important one into my calendar as an event with the current day and time as the time. If I had another one on my calendar that I hadn’t yet gotten to by the time that this new important one appeared, then I’ll put that other one into the external repository and take it off my calendar. This way, my calendar is clear except for the one most important item that I must be doing right now. And so it’ll be obvious that it is the most important and should be done now. Edit: This post was previously published at: wieldlinux.com/2016-05-01-synchronous-asynchronous-flow-calendar.php --- wieldlinux.com I’m taking my calendar productivity to a next level. I’ve made calendar changes and, as a Software Development and Support Engineer I stopped using shared calendar, instead using a local calendar. This has been an improvement. However I need to check my calendar more often so as to not miss anything. But not check it *too* often so as to not waste time. Here’s my new strategy. I set 30 minute pomodoros. Every time 30 minutes rolls around, I stretch, breathe, check email and check calendar. This only takes between 4-10 minutes to do, and it breaks my Software Development and Support Engineer schedule nicely to clear my mind and increase my productivity. Edit: This post was previously published at: wieldlinux.com/2016-04-30-local-calendar-pomodoros-productivity.php --- wieldlinux.com Recap of 2016-04-10 Open Source Volunteer Software Development and Support Engineer “Mentorship” Previously I had blogged about my plan for my Open Source Volunteer Software Development and Support Engineer “Mentorship” ( http://wieldlinux.com/2016.php?2016-04-10#2016-04-10 ) I proposed to chat, support, and report on WordPress support for thirty days. This is the follow-up “final report” of what I learned! I learned that I wanted to spend more time in-person with colleagues, and spend more time working with geographically local colleagues. Especially during the last 5 days, I tended/switched to calling local colleagues on the phone, and planning to go to the local April 2016 Boston WordPress meetup in-person. I’m disappointed I couldn’t make it through the project fully, however I’m joyful that I switched my focus more to professional networking with geographically local software-development-and-support professionals on the phone and in-person. I learned I didn’t have the endurance, grit, or focus to finish the Work-project. Partway through, I blogged again to change the project proposal, proposing to shorten the project length and double the daily office-hours length. ( http://wieldlinux.com/2016.php?2016-04-15#2016-04-15 ) However in the end I only ended up actively volunteering on 8 of the 15 days. I also learned about the following: Olsen Light theme. https://wordpress.org/support/topic/streched-paypal-buttons-how-to-unstrech-them?replies=5#post-8254375 A bit about a couple of my public forums colleagues in the slack #forums channel. Some options for hosting an RSS feed, i.e. the existence of Tiny Tiny RSS ( https://tt-rss.org ) Yikes mail chimp plugin and Shortcodes In Menus plugin. A bit about trying to make a GDP map of cities using the Visualizer plugin https://wordpress.org/support/topic/problem-with-regions?replies=4 I chuckled because of the language creativity when I read what I suspect is the coining of the phrase “…I’m facepalming the hell out of this. …” written by a plugin author on the public forums ( https://wordpress.org/support/topic/please-backup-more-than-db-wp-content?replies=14#post-8143933 ) I think what I may have been looking for in the first place was to learn, but also to in-person network with local Software Developers. Edit: This post was previously published at: wieldlinux.com/2016-04-29-recap-support-engineer-mentorship.php Edit: 2016-12-07 fixed broken links. --- 2016-04-24 wieldlinux.com PHP HTML Calendar Codes for Studying how a Calendar can Work in LAMP As a Software Development and Support Engineer, I’m interested in calendar computer scripts because practically everyone uses a calendar every day, and a calendar is included as a sub-part of many other computer applications, even if the application itself isn’t a calendar application per se. Understanding how a calendar works in computing means understanding about how times and dates work in computing. By learning how a calendar script works, I believe it will help me grow as a Software Development and Support Engineer, to develop applications that use calendars, dates, and times, and to support users in using applications that use calendars, dates, and times. I found two relatively simple examples of source code for a PHP calendar script. I can use these to study and learn how the code for a calendar LAMP web application can work. The calendar example from Chapter 24 of: “Sams Teach Yourself PHP, MySQL and Apache” by Julie Meloni Sugar Events Calendar Lite (plugin for WordPress) ( https://wordpress.org/plugins/sugar-calendar-lite/ ) The former is a PHP/MySQL powered calendar. I was lucky to get access to a copy of the book from my city library. The latter is a WordPress plugin (ultimately powered by PHP/MySQL but through WordPress) downloadable for free from WordPress.org. These are two source code scripts that as a Software Development and Support Engineer, I can use to study how a PHP calendar script can work. Edit: This post was previously published at: wieldlinux.com/2016-04-24-php-calendar-source-code.php --- 2016-04-23 wieldlinux.com It’s Important for a Software Development and Support Engineer to Recognize Indirect and Direct Communicators and Thereupon to Over-communicate Back to Them Through past SDASE (Software Development and Support Engineer) experince, I’ve been in a postion where a co-worker directly told me what they needed me to do better. I remember having felt some kind of resentment and been upset that they had been so blunt with me. I’ve also before been in a position where a co-worker indirectly implied that I wasn’t working hard enough. I had to figure out myself through reflection afterwards on what they had said and how they had said it. I remember having felt some sort of resentment and been that they had been so indirect and hadn’t confronted me and hadn’t explicitly told me what they thought of my performance. First, let me say that anyone reading this at this point must think I’m a terrible worker. I’m working on it! But that’s not the point; the point is how I can do better to handle when I’m criticized. What’s the take-away on this? I need to find a better balance wherein I over-communicate in *both* of the above cases. As a Software Development and Suppor2016-t Engineer, in the above-described former scenario, I need to over-communicate by confronting the person and telling them that I think they’re directly telling me that I’m not working hard enough, telling them that I think that they’re being direct about telling me about it so that everyone’s clear, telling them that I won’t take it personally but rather I’ll take it professionally, telling them what I think and feel about it, telling them what I’m going to do about it, and then I need to solicit their response. (to listen) In the above-described latter scenario, I need to over-communicate by confronting the person and telling them that I think they mean that I’m not working hard enough, telling them that I think they’re being polite by not telling me that directly, telling them what I think and feel about that, telling them what I’m going to do about that, and then I need to solicit their response. (to listen) So to recap, for a Software Development and Support Engineer, it’s important to be able to recognize and to be able to over-communicate with different styles of communicators people who indirectly indicate what they need from me vs. people who directly tell me what they need. No matter which style the other person uses to communicate to me, It’s best for me to respond by over-communicating directly back to them. Edit: This post was previously published at: wieldlinux.com/2016-04-23-direct-indirect-confront-overcommunicate.php --- 2016-04-22 wieldlinux.com Maintain the Best Day-job Salarformance and Blog It A while back I had the idea that salary (pay rate) was connected to performance. I thought of calling the concept in this idea one’s “Salarformance” or one’s “Performalary”. I had the idea that under this paradigm, motivation to get a high salary would motivate me to perform well. I told myself that I would have to keep in mind that I was producing the day-job salarformance for myself. I told myself that is where all of my motivation would come from. However althought I knew salary was important, and was to an extent motivating, I still had this feeling that I was missing the motivation that came somehow from a feeling of alignment of my career goals with the goals of my then-current day-job. And I still thought about how would my performance at my job stay aligned with others in the industry at different organizations, how would I develop skills, and would I have to blog about my salarformance experience in order to stay in touch with other professionals? I thought my professional blog would tie my private then-current day-job to other similar industry-wide day-jobs and thus would be my career. “Blog it or it didn’t happen”, I thought. The conclusion it seems is that salary is not that closely tied to performance. It is more related to other motivations; driven-by / tied-to industry knowledge, professional career goals, and sharing/blogging with others. I’m still figuring this part out. To recap, the guidelines of my career remix of that time had been: My number one career remix goal was “the best day-job salarformance and blog it” I’d focus all my effort on getting-the-best-day-job-salary-by-way-of-improving-my-day-job-performance-and-blogging-it I’d take notes as I go and I’d blog about what I had learned. However in hindsight, in summary and upon reflection, the conclusion is that although its important and the salary isn’t what motivates peformance. Although I’m still figuring it out, salarformance is tied to alignment of job with career-goals, aligning with others in the industry, and blogging/sharing with others. Edit: This post was previously published at: wieldlinux.com/2016-04-22-salarformance-and-blog-it.php --- Update to Previous Plan for “2016-04-10 to 2016-05-10 Open Source Volunteer … Work-project )” Post Previously I blogged “Plan for 2016-04-10 to 2016-05-10 Open Source Volunteer Software Development and Support Engineer “Mentorship” ( Job-shadow / Informational-interview / Work-project )” ( http://wieldlinux.com/2016.php?2016-04-10#2016-04-10 ) Update: Today Mid-stream / in-flight (meaning: while the project is already underway), I’m halving the project length while doubling the daily-office-hours-time-length. So I’ll do 15 days (with “final report” on day 16 (days 1-15 being April 11th to April 25th, and day 16 being 2016-04-26)). And “office hours” will become 5am-6am daily. I think that this change will both allow the Work-project to be be more impactful to the community, as well as allow deeper learning (quicker iterations of deeper dives) for myself. Edit: This post was previously published at: wieldlinux.com/2016-04-15-work-project-plan-update.php Edit: 2016-12-07 fixed broken link. Edit: Follow-up note -- See the next follow -up to this post, here: "Recap of 2016-04-10 Open Source Volunteer Software Development and Support Engineer “Mentorship”" ( http://wieldlinux.com/2016.php?2016-04-29#2016-04-29 ) --- Plan for 2016-04-10 to 2016-05-10 Open Source Volunteer Software Development and Support Engineer “Mentorship” ( Job-shadow / Informational-interview / Work-project ) This post outlines the plan for a learning/growth project for me. The goal is for me to work with users towards solving their problems on the WordPress.org support forums, and to, in a structured way via this volunteer work, to myself grow and learn about Software Development and Support. Today is day 0 of the plan. Here are the details: Starting 2016-04-10 to 2016-05-10 (days 1-30), with “office hours” of 5:30am – 6:00am (New York time), I’ll: On days 1-30, daily, during my “office hours”, check in on the wordpress.slack.com #forums channel. (Say hi, write what’s happening with me, read/ask what’s happening with other members of the support team, be social. Don’t be shy to “interview” (write to the channel to ask even one short sentence is fine) others on the channel what they are doing in terms of open source WordPress Software Support and Development. If I have a question, don’t be shy to write out onto the chat to ask the channel/team the question. Then read and acknowledge any replies. Thus my peers can be my “mentors”. ) On days 1-30, daily, during my “office hours, “Do the work!”(Read & Write — read & reply threads on the http://WordPress.org/support forums. Don’t be afraid if on a certain day, I read 10 (or 30!) threads and thus just “shadow” whats happening on forum threads. That’s learning too and is participating. Replying is good too, when it adds value.) Take a private note what happened (for my report later) On day 31, that’s 2016-05-11, compiled from my private notes on days 1-30, write and blog the “Final report”. This should be a list of bullet points, or a list of paragraphs, whenever possible including details (links and dates+times etc.) describing what happened during days 0-30. This has been a description of my plan for a 2016-04-10 to 2016-05-10 Open Source Volunteer Software Development and Support Engineer “Mentorship” ( Job-shadow / Informational-interview / Work-project ). I’ll see you on the forums on the chat! And look for my follow-up blog post “final report” on day 31 ( May 11, 2016). Edit: This post was previously published at: wieldlinux.com/2016-04-10-open-source-volunteer-mentorship.php Edit: Follow-up note -- See the next follow -up to this post, here: "Update to Previous Plan for “2016-04-10 to 2016-05-10 Open Source Volunteer … Work-project )” Post" ( http://wieldlinux.com/2016.php?2016-04-15#2016-04-15 ) --- wieldlinux.com Reasons a Software Development and Support Engineer Should Strive to Kick Ass at Their Current Job Reasons a Software Development and Support Engineer should strive to kick ass at their current job (do their current job well), that have nothing to do with their current job. In other words why it benefits one’s *own* career to perform well at work. The scope of this idea is that this applies to all jobs past, present, and future. This can be seen as a pep-talk for *anyone*, however may be especially poignant for a Software Development and Support Engineer who either isn’t currently getting a lot of job satisfaction at their current job, or feels underappreciated by management at their current job, or feels underpaid, etc. etc. The point is that as a Software Development and Support Engineer there are *big* reasons for performing well, that benefit a Software Development and Support Engineer as an individual professional — reasons that have nothing to do with how much one’s currently paid, nothing to do with how much job satisfaction one’s currently getting, and nothing to do with how (under)appreciated-by-management one feels at one’s job. Of course, it doesn’t hurt a Software Development and Support Engineer’s employer either that one is high-performing! It’s a win-win — it’s good for the employer and the employee. Reasons: 1. The colleagues at one’s current job will be needed to be references in the future, years down the road. Not only for changing jobs to a different organization but for promotions within the current organization. In other words people hire and promote a person who is regarded by their colleagues as a professional high-performer. 2. If a Software Development and Support Engineer wasn’t kicking ass at their job with their current organization, then the Software Development and Support Engineer would be kicking ass at their job with another organization. In other words, no matter the current situation at ones current job, it’s still in one’s interest to strive to be a high-performer. After all, as a a Software Development and Support Engineer, if I wasn’t doing a kick-ass job at this organization, then I’d be doing a kick-ass job at some other organization. The point of this pep-talk is that as a Software Development and Support Engineer, the above-mentioned are some *big* reasons for performing well, that benefit a a Software Development and Support Engineer as an individual professional. Edit: This post was previously published at: wieldlinux.com/2016-04-09-reasons-to-kick-ass.php --- wieldlinux.com One Reason Why I Like Doing Software Support and how it Relates to Quality Software Customer Support and Development Engineering Although its been years since I started Doing Software Support, I just now thought of this aspect that of why I like it. Triggered by something I saw on a software support forum. I like responding to each user’s individual question individually. That way I get the feeling I’m helping that one person with that one problem. It preserves the human aspect. This has nothing to do with pointing the user to an existing document, no matter how well-written the document is. There’s always phrasing that could be made different- improved based on each individual user’s individual question. So copy+pasting, or linking to a guide won’t give the same feel. However how can one balance this with doing software customer support as a job, representing a business? So many business models don’t allow for the high-touch required to respond individually to each customer inquiry. Thus strategies such as automated replies, copy+pasting, snippets, and pointing to existing documentation are widespread. I think the take-away here may be that different companies do it differently. I think one big factor might be in how much the solution costs and what level of service the customer expects. From having listened to software support podcasts and read software support chats and blogs, I understand that some companies charge more and put importance on customer service. Like some high-end department stores that provide professional shoppers, one-to-one customer service, and also happen to charge higher prices. But their customers like this and can and do pay the higher prices. On the other hand, some SaaS companies never talk to their customers on the phone, and use automated email replies mixed with snippet and/or copy+paste replies. Where’s this thought process going? I’m reminded of what I’ve understood personalities, including Jeff Vincent of supportops.co fame, as in my mind the personality who I’ve listened to this most often, refer to as “the best support is no support”. Which means that designing or improving or fixing the product to the extent that it does what the customers need it to do, so much so that the customer never needs contact the support channel. I think Jeff Vincent’s personality also said or quoted something like ‘automate wherever possible, and be intensely human everywhere else…’ or something. This leads into the world of Software Development. Maybe even into the world where a Software Support Engineer also plays the role of Software Development Engineer (Software Developer), thus becoming a sort of Software Support and Development Engineer. What is the conclusion? 1. It’s human and enjoyable to craft a unique reply to each software customer support request, 2. The paradigm that allows this is the one of the high-end personal-shopper expensive excellent-1-on-1-service department store, 3. Another paradigm that allows this is the one where the product is developed such that the customer never needs to contact support --- 2016-04-01 The Importance of Software Customer Support to a Software Developer of Plugins for WordPress Listening to Officehours.fm podcast – “A Former WooMattician Sets Out on His Own, Episode 67”. At about 10min.55sec. into the podcast, until at least 11min.55sec., Carrie Dils and her guest Barry Kooij are discussing the importance of Support. At this point of the podcast, they discuss for a WordPress plugin developer, what is the importance of customer software support. One thing Barry Kooij says is that he thinks supporting the existing customers is very important. He indicates that his habit is to first support the existing clients, then second proceed to work on developing the product. --- Inspired by the Persona of Jeff Vincent – Clearing my Calendar to Zero and Managing my Software Developer Career and Managing my Life I became exposed to the persona of Jeff Vincent through supportops.co podcast about two years ago. Jeff’s comments have inspired me. Today I read some posts on Jeff’s blog, and read the post “Zero” which I’d read before. http://jeffvincent.me/zero In the post he wrote “Instead of supporting the status quo of recurring meetings, I re-examined each for it’s value…” This time around reading this, I’m inspired to action. As a result, I am clearing my calendar to empty, and re-adding only the essential items. It feels great and is taking the weight of unnecessary to-do items out of my life. ( and, also inspired by Jeff’s blog post, I am keeping in mind: “…(if they are really important, they’ll come back)….” — as Jeff wrote in his other “The White-Space Day” post on a similar topic ( http://jeffvincent.me/zeroing-out ) ) Thanks to Jeff for having blogged this. I’m glad I read it. I’ve become inspired, acted on it, and it is helping me manage my Software Developer career and manage my life. --- Spend a Medium Amount of Time Each Day Talking With Colleagues 2016-03-01 Even though it’s the first part of my twitter bio (blog tag line too), I may not blog about it a lot. It’s time to blog about talking with a colleague. that’s what this post is about. (twitter bio: “Talk with a Colleague, wield linux to ….”) As a Software Support and Development Engineer, I need to spend a medium amount of time each day talking to colleagues. Ok, but what does this even mean? I mean, it’s not good to too-quickly rush by colleagues every day, either not saying hi or merely saying a quick hi. At the same time, it’s also not necessary to go too far and strain oneself to try and grab breakfast or lunch with each one of my colleagues every single day. I mean that people like to spend a medium amount of time talking. If there’s less to say, then the conversation could end after half a minute naturally. Or if there’s more to say then the conversation could go on for ten, fifteen, or more minutes naturally. What’s the benefit? It’s normal, it will allow an engineer to fit in, will allow for a healthy life and career that wouldn’t be possible. If too rushed or too strained, or if one talks too little or too much with colleagues, then an engineer will have a hard time fitting in. In conclusion, when striking up (going into) a daily “hello” type of conversation with each of my colleagues, as a Software Support and Development Engineer I should expect to be able to spend a medium amount of time. --- For a Software Support and Development Engineer the Importance of Being Able to Sell 2016-02-01 For a Software Support and Development Engineer it’s important to be able to sell. In other words one might say it’s important to be able to bullshit (bullshit in a good way). In *other* other words, to be able to convince others to do stuff- to argue well enough to win an argument in one’s favor. (or in one’s department’s favor, or in one’s colleague’s favor, or in one’s company’s favor, or in one’s client’s favor, or in one’s shareholder’s favor, etc. etc.) This could be considered a soft skill or a people skill. Therefore why is it important for a Software Support and Development Engineer to have this skill? A Software Support Agent or a Software Dev. must be able to sell in order to do some critical things: 1. win the argument to get resources for one’s department (get hardware, software purchases, get funding to attend relevant professional conferences, etc.) 2. to convince one’s boss, peers, or client that the next-step course of action that I’m proposing on a project is the best next-step *even if it is a non-trivial task*, 3.) to sell themselves to get a promotion, or even to get the job in the first place. It’s important for a Software Support and Development Engineer to have the soft skill of selling. It’s important for us Support Agents and us Devs to be able to bullshit (in a good way) in order to win our arguments in our favor. It enables us to do the best job that we can! --- Professional Networking (WordCamp style) 2016-01-01 My first listen to Office Hours.fm podcast hosted by Carrie Dils. Started with episode 70 – “Taking Your Freelance Business To The Next Level, Episode 70”. 31 minutes (so halfway) into it, the panelists have discussed the WordPress ecosystem where freelancers form partnerships based on their skillsets / strengths. The panelists talk abou how the center of this — where the magic happens — is by freelancers / professionals meeting at WordCamps and Meetups. The podcast show host and guests talk about how people stronger in sales and talking with clients go to a WordCamp and may strike up (a) friendship(s) with someone who is good at creating product. The man guest mentions how, as someone strong on the talking-to-clients / client-relationships (meaning sales) end of things, he really took the opportunity to find and seek advice from a product person at a WordCamp. Someone mentions how the key here is that friendships and trust grow across multiple consecutive in-person events, and then later business partnerships naturally form more easily because that strong personal trust is already there. What strikes me listening to this podcast is that some people are most definitely more on the product/coding side of skill strengths, yet these same people might feel like there’s no one who’s interested in their skillset. And yet here is someone on the podcast saying they are looking for someone like this – the person is looking for someone strong on the product/coding end of things. Looking for a Software Development Engineer (Looking for a Software Developer) To me listening to this podcast, I might say that described in a single term, what’s going on could be called Professional Networking. However I don’t recall anyone on the podcast using that term. In any case, it’s clear to me listening to this that as a Software Support and Development Engineer, one constantly needs to do this- network with all of one’s colleagues to keep professional relationships past, present and future!