That's right. It's all part of the back-and-forth of good faith.
2,691 karma · joined August 12, 2011
This situation sounds more like people trying to cover their ass so they aren't blamed for something later. Work to get things accomplished, not to avoid some kind of criticism.
So, rather than being these types of people -- be a person who helps get something accomplished and maybe improves this situation along the way.
I'd suggest that "good faith" means turning those stupid orders into sane orders. In a case like this, help your manager -- educate them.
If your relationship is tenuous, I get this can be hard. Show your good faith and explain to your manager in clear detail why something is stupid. Manage up, as they say.
You should absolutely do that (I tell my team to inform me if what I'm asking doesn't make sense.) If I'm coming to someone with a request, it's because I think they're the right person to address it. Just tell me if I'm off-base.
FWIW, I encourage everyone to not care about the hierarchy, so that may not work in every place.
(1) Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
(2) If you're a manager/leader, there are no "one-off" requests. Any ask carries an implicit priority over everything else. You have to work within the overall system and environment, otherwise you are forcing your team to make choices about those things. Don't be this kind of manager/leader.
(3) If you're the one receiving an ask, help your requestor understand what's involved. Eliminate implicit assumptions; that's where the dragons lie. Communicate, inform, educate. Nail down what the requestor wants and be sure you both agree.
We do these things in the name of efficiency, of not wanting to waste time if it's not necessary. I've found if we all try to help each other in these requestor-requestee situations, it generally makes life much more tolerable.
"Enterprise-y" appears to be a catch-all term for an organizational culture built on a foundation of lack-of-trust where interactions among people need to be gamed in order to accomplish...well, anything. And the presentation covers strategies of how to be effective in that kind of environment.
I like some of the tactical suggestions, which apply in any organization trying to get things done. I dislike all the actions that are based in hidden agendas or ulterior motives, no matter the intent.
As always, your mileage may vary.
- last: `git log -1 HEAD --stat`
- past: `git log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --numstat`
- save: `!git add -A && git commit -m 'save'`
Need to differentiate between finished FEATURES and finished software.
I think the intended thought process is: don't prematurely scale. Wait until you need to.
> NEVER start with the software
As a long-time (old) engineer, historically my mindset was to rush into problem-solving mode by thinking about software-based solutions to everything. After learning from a failure or two, I recognize how that might work for me but doesn't necessarily contribute to solving a problem for a customer.
I understand how to solve problems with software, but my key to successes has been to really understand and define the problem to be solved. This generally takes so much more effort than surface-level assessments.
The best across-the-board advice that I've heard from others:
- Own it. Be the best operator for everything in your business.
- Scale last. Very few companies have failed because they couldn't scale the business (but did everything else right).
- Keep at it. Blood, sweat and tears.
I'm not sure what this means entirely, but across our projects we have some with different workflows than the others. These are necessary in that we have certain workflows that must meet compliance requirements, and those workflows are the best way to ensure we execute those. In other projects, they are less onerous and apply to different kinds of work (so, different workflows.)
> Our "home" screen is intended for individual users to have pre-defined organization and not needing to set up their own dashboards
This is good, but we generally keep our exec leadership out of JIRA (they don't really have the context for the details.) Our users can design their own dashboards, but that's a personal preference. We use the standard views.
> making the goals and work more clear
I would prefer to see more fall-into-the-pit-of-success for the equivalent of JIRA stories to be more oriented toward the outcome or feature or capability, as opposed to the accounting/I-got-receipts feeling I get from JIRA. While story points are fine, I prefer a focus on clarity and a better measurement for effort than the subjectivity of a team's interpretation of the fibonacci sequence.
> for Confluence fans, we come default with docs and (on cloud) we have whiteboards
So, Leantime includes a markup engine as well as a whiteboard feature? If I already have a deep investment in other tools that do those things, how do they integrate?
Since these are designed to help a team deliver the best bang-for-the-buck at a given point in time, I've found proper assessment of actual urgency and importance are the biggest success factors.
Can't express the number of times that an urgent or important need that was identified was addressed by my team, with nary any impact.
What are the key differentiators in how this is easier specific to those that use JIRA?
Not every problem I'm solving is just a hunt for the code implementation. I like to reason about solutions beyond the syntax. I use pen and paper a lot, including for code, and I'll use shorthand to represent longer-form code blocks. I find that approach better because I can hide the noise that code blocks can introduce in an IDE. I want code to support my solution -- not a solution to fit into code. IDEs and frameworks can have that affect on people, in my experience.
As with this comment and the one preceding it, your mileage may vary.
I agree with having helpers to understand how tooling works. Any resources that increase understanding of how to use a tool to it's full capability is productively beneficial. (Hat-tip to anything that unpacks all the `curl` switches.)
Here's where I have disagreement: an old boss of mine once said "don't worry about the tricks of the trade; learn the trade." That's very contextual, but sometimes understanding the core first makes the rest of it easy. And understanding the core takes both effort and increases cognitive load, so I understand why one might not go that route.
So, for me, I always try to keep a balance between trying to back my way into execution via those helpers, and recognizing when I need to take a step back and learn at a bit more core level.
Her down-to-earth approach is refreshing, that's for sure.
While that's a ridiculously low number (something tells me our definitions for "good starter homes" don't align), it's not THAT far off from similar properties in my wife's hometown in the midwest.
But let's _also_ talk about aspects of locality that affect quality of life (and along with it, real estate value):
- Neighborhood schools: absolute crap. 1/10 on the GreatSchools rating system.
- Civic resources (parks, libraries, etc.): none within a short driving distance. Parks not maintained. Libraries closed, partially due to the books they made available (this is one of those areas where books are being banned).
- Local employers: forget about it. The local industries and companies that setup shop there left town long ago. Nearest town where you might have a career of some type is about 70 miles away.
- Healthcare: some kind of urgent care, but it's of middling-low quality. If you have a semi-serious condition, you've got 100+ miles to anything resembling a hospital.
- Crime: exactly what you would expect. There is no opportunity, and people get desperate. Heavy, rural drug addiction.
- Population: trending older, as most people are retiring. People of means fled the area due to lack of opportunity.
- Transportation: there's a new highway bypass going way outside of town! Oh, but local transportation is entirely unreliable. No buses, taxis, uber, etc.
It's not part of an overpopulated metro, but that's what you get in this particular neck of the woods.
The trunk branch, the Bugzilla list, the OS/2 support, the user forums, the multi-hour build process, the XHTML 1.0 compliant badge on the https://www.openoffice.org/ homepage .....
Reminds me of the good old days.
Microservices are simply another approach to solving a problem. Another tool in the toolbelt.
Use it wisely, as you would any other tool in your toolbelt.
> failed a number of technical interviews because I can't make architecture diagrams
I would caution against correlating interview failure to a lack of diagramming skill. Diagramming is a teachable skill; how to formulate architecture is much more complicated. If I am considering hiring someone who I see can design strong architectures but couldn't represent that in a diagram, I'm probably not dismissing them because of their drawing skills. But that's only when I believe they can design an intended architecture.
> I can't for the life of me draw the architecture of anything
I had an engineer on one of my teams who had the same problem. With him, he understood some things but in other aspects he was more murky. So, I asked him to start by writing down the architecture. Literally, write words and sentences that describe the collective of systems, i.e. Service "A" is a REST API, and it connects to Database "B"; a client connects to Service "A" over HTTPS, etc. etc. I don't know if this would help, but if you can do that, you can start to translate the words to pictures.
> I don't know how people learn to do that
By doing. I don't know anyone who has ever been trained to create an architecture diagram that knew what they were talking about. Just start small, and then ask someone to describe it back to you. When you begin to hear what you consider to be correct, you'll know you're making progress.
> I've never used diagrams in my day-to-day work
This tells me a couple of potential things: you're possibly not working in complex or large systems, or maybe are not responsible for communicating those systems to others. "Complex" is a relative term, so interpret that as you may. Ultimately, arch diagrams serve as a way to visualize complexity with the goal of letting others understand.
As general advice for those early in their career, I find this to be inadequate. These tactics (no offense to the CS peeps) might "get you noticed", but that won't sustain if you don't back it up. A github account or a cert from your favorite uni might potentially get you in the door somewhere, but you will have built expectations about what people can expect from you once you're in the fold.
Very few have ever kept a job because of their G/H reputation or GPA. The number of times I've seen a hire who was "noticed" that failed in their new role is almost meme-level. It's amazing how quickly credibility and reputation from that get-you-noticed effort can be burned down.
By all means, make logical efforts to get noticed, but that will only take you so far. You will significantly improve that signal/rep when you translate your previous activities to skills, learning, and value as you go forward.
Nonetheless, I was referring to the sales pitch. And Jobs never let facts get in the way of a good story. :-)
All the adages listed here make perfect sense, but they don't succeed in a vacuum. Servant leadership is great, until individuals disagree with product strategy and priorities. Addressing low performers is great, until a company's HR policies make doing so onerous.
I could go on, but there are often many things outside of your control as a leader that directly affect your capability to manage. It's all part of the job and something to account for, but set your expectations accordingly.
The thousand-songs-in-your-pocket sales pitch was more than lifestyle/concept -- it was an actual feature. All of the other players at the time were big & bulky because the components they used for storage & battery required the corresponding form factor. The "pocket" part of the sales pitch was exactly that: the ipod physically fit in your pocket because the components were smaller and more integrated. In the stage demoes by Jobs, he shoves the ipod into his jeans.
To the author's point about "you pay for the problem it solves, or the needs/wants it fulfills", the implied need here was that you need this to be small and out-of-the-way -- not a miniature home-stereo attached to your belt.
And not to pick on the author, but I don't find the ipod reference very applicable to the case of communicating with your consulting clients. Sure, you have to speak to your audience -- but direct 1:1 contact with a handful of stakeholders is hella different from millions of consumers who never asked you for a specific set of features and a timeline.
Development using those IDEs are not well suited to inputs from anything other than a keyboard (or keyboard-translator.) Too many functions tied to keys and such.
I'm uncertain why anyone would think this somehow magically changes because of the tablet form-factor.
I expect the next phase of these sites liberally employ the use of AI tools for image generation, i.e. "an apartment with a lawn mower in it".
If so, this is some weak-sauce when it comes to anti-competitive behavior.