Real paint by numbers, follow the steps tdd is awful, but writing some high level tests first and building towards that have helped me from falling into the land where I write code for a day then spend a day trying to form fit in tests

If there are any PM?s in the thread or know a lot about the topic and are willing to answer Q?s can you send me a message?

Let it out here I say - the public needs to know. I'm not a PM but I've been a lead working closely with PMs for over a decade. Ask away.

I just coded a shared logger component - using lambda layers, from scratch, and it worked the first try - on my local and on AWS. Those startup idiots who all rejected me have no idea what they missed out on :P

However it also revealed the limitations of console.log - which AWS seems to recommend.

Yeah [Object] isn't really gonna do. So I found this blog which says just start with JSON logging and use whatever you normally use (bunyan for us). So I have to throw out my beautiful hole in one logger before it even gets off the ground.

Next attempt: [Object object]

Lol I'm just way in over my head and am basically operating on pure charisma and force of will at this point. I can only read so many books, I just have a few questions on how Product/PM teams interact in a well functioning company. There's also a third department, sales - which doesn't come up a lot in my reading. Our sales head is basically our Product manager right now so the roles are really muddled and it's hard to translate everything I'm reading into my situation.

But yea basically just trying to get an idea of how the whole customer -> product manager -> requirements -> engineering team flow goes in other environments or if it even goes that way.

Where I was product worked with the C staff and sales to develop the road map.

Quarterly, product, stake holders, and engineering managers would prioritize the items on the road map based on new customer go live dates, expected sales, or new product designs. That's the first time it would all go on a wall so dependencies could be seen and we could figure out what the timing of things was going to look like.

This map drove sprint level planning, it's how the back log was filled and prioritized. The engineering teams would point and plan the sprints.

As things changed the plan was re-evaluated.

Project managers were some of the stakeholders in the road map planning session and were involved in status updates. We were BtoBtoC and the only projects that had PMs were bringing new customers on board or sustaining existing customers. Any pure engineering projects were managed by engineering managers but followed the same pattern.

Customers primarily interacted with PMs after the sales phase, product would talk with them as well but my sense was most customer inspired feature requests came through PMs.

Oh PM = product manager, not project manager?

We also had program manager - which I'm pretty sure just exists because project manager manager sounds silly.

PM typically refers to project manager, that's how I was using it.

I have another big meeting tomorrow and I'm trying to translate a lot of concepts into what we have (and then sell it) and it's kind of rough. Thanks kerowo

Yeah, our "projects" were essentially bring in new customers. While I was there PMs were account managers, customer managers, project managers, etc. The place where I had a true PM they basically dealt with higher management, drove the agile ceremonies with product, and ran interference for the team.

We have three types of projects:

Maintenance of our existing product that's actually been successfully released (pretty low effort)

Customer demos (we are having a really bad time with this)

New product development (what I have mostly been working on)

But a problem is we often define a complete implementation of an application before we even speak to a potential customer, but the higher ups have admitted this hasnt worked and we're changing

Is every demo a one-off? I mean is there enough difference between demos that the steps drastically change? It seems like there should be some room to standardize demos; something like:
Have a demo environment set up that has the latest demo running with good data.
Have a new demo environment where new demos are set up
Switch between them

The hardest problems we had with demos was sales people not giving notice that a demo was happening and having to set up a demo quickly. Fortunately, we had tools and get demo users and data into an instance fairly quickly, but it was always frustrating to have a fire drill because some sales guy wouldn't send out an email.

I don't know what your product does or what your demos look like, but we figured out where the pain points where with our demos; and came up with tools to automate or mitigate those problems. It's going to be like any other process; figure out what you're doing, figure out what you should be doing, figure out how to get there. It's getting the right people into the room that's difficult.

In this case, the demo was a one off - a very very major company wanted us to run our software on an extremely specific environment, with extremely specific hardware requirements, with basically no help from their end. So it was a learning experience but there is likely another major one coming soon. We have similar problems from sales, further complicated by the fact that they are remote.

I know exactly where the pain was and unfortunately a lot of it is a resource (personnel) issue that I'm not sure how to solve but I'm 100% positive if I was in on it it wouldnt have been nearly such a total mess.

There are probably gonna be more 1 off demos like this, definitely a major one coming up that I am going to helm (I asked to). I'm trying to figure out what mistakes were made so I can avoid them this time but I'm coming in kind of at the ashes of the project at this point.

My current project is trying to sell a process plan to upper management - they think the main problem is the communication mediums we are using. I think they are under the impression that there is a magic bullet software solution and there isn't. I agree it's part of the problem, but the main part is mostly organizational and cultural. So now i have a chance to influence the organizational problem so I can do the actual job I was hired to do - without this, I'm really just a glorified note taker/task pusher and part time dev which I don't want to be. But to influence this I need a better understanding of how things work in the real world.

I am getting this from a good book I'm reading called "Agile Development in the Real World" by Cline but I am only ~25% of the way through.

Sounds like you guys need a seasoned agile project manager. They aren't that expensive - you can hire one on contract.

It's great that your learning and seeing this side of things. But I get the feeling a lot of what your company is struggling with has already been solved at bigger/more-experienced-with-agile companies. You might want to try to leverage someone with that experience.

As much as I rag on my old company - one thing we were topnotch at was project management. As a developer I just showed up for the standup every day and counted on my PM to bug me about anything I was forgetting. It was great to offload the organizational/ownership side of your brain and just focus on code.

You want me to ask them to hire someone to do my job

I recently read this article regarding the efficacy of unit tests and think it may be of interest to you.

No just get a consultant to come in. We did that at my old job and it was a big help to modernize our processes.

Aren't you still a developer? Or are you a full time project manager now? If so, do you really want to be a full time project manager? If you do then great.

I delegate myself programming tasks or do stuff no one else wants to do. So sometimes it?s full time-ish. I do a lot of our testing. I can do both, the PM stuff really only takes about 20 hours a week at its worst. But if I can?t do both I can just delegate myself fewer tasks. Like this week for instance, is the first one where I actually became nearly too busy to do both so now I know I need to start backing off dev stuff.

We are so small and there?s a lot of work so being flexible is valuable, I think. Idk. I can?t SERIOUSLY contribute to any project. I can only do really do light bug fix stuff or write tests.

Re: a consultant, yea it?s a good idea, they?re likely to think it?s overkill. Me running the actual sprints and managing our issues/tasks/backlog is going really well. I think we are close to something functional.

I wouldn't recommend a consultant if I were you. You are doing a great job making yourself valuable and irreplaceable now. Keep that up.

It?s gonna be a hell of a resume item if i can pull it off

For a project manager yes...

I mean I could seriously tailor my resume to go either way at this point. It looks like I may be doing a lot of development in the next several months - we just lost our main guy for our main project a month ago. There was only one other dev that knew that codebase. Then he gave his two weeks today - my boss is having him do a knowledge dump to a newer hire and he wants me to sit in on it. Yikes. I gotta ask him if he expects serious development from me because I honestly do not feel up to par. But it is very scala and java heavy and I am far more comfortable with programming in those languages than in C.

I got a formal email about my raise and I want to just reply ?sounds good but let?s tack on 10k to that number.? But idk. Kind of greedy. But I mean **** - I?m reading an average of like one book a week to try to get up to speed on stuff, regular management stuff, my testing/QA stuff, regular small dev tasks, and now I?m likely to have to spend this entire weekend studying hadoop and refreshing my scala just so im not completely lost next week during the knowledge dump. That?s a lot of ****.

10k/yr is nothing to you.

Stop thinking short term.

You are building skills that will allow you to do whatever you want at any company.

Continue to dive into development, you are adequate, you will learn.