Software Engineering Goals: Attempt 2; Delivering Tasks and Designing Effective Solutions To Product Features or Small-Scope Engineering Challenges

Due to my passion and my strength and my inspiration - I have decided to give this one a second go. I am really really determined to do this one properly. And to do this whole thing properly. So here is goal number 3 again, with my revised/updated thoughts.

So here it is one more time please, in full, in all its glory, and all of its fullness

"Delivers tasks and designs effective solutions to product features or small-scope engineering challenges." Okay so yes let me try this out one more time then please thank you. I am sorry if it repeats itself from the last time round. It's just that I want to make sure that I have understood this one properly please. Thank you. So in order to explain this goal to you I want to take you back to the very beginning... of a feature request. Imagine that the feature request had just come in.

Let's say that there are some new requests: "in this thing that we normally do... we need this extra new thing added in please... thank you." So I could almost break it down into two bits. So imagine a new feature comes in.

And so imagine, imagine, just imagine if I could think to myself, "Well, actually..."

"Well, actually..." well, actually... Well, actually:

• Oh okay, for this new aspect of the feature that's doing X,Y, and Z, that's what we need to do...
• We need to:
• "Read data from here."
• "Pull something else from here."
• "Write the code for the new aspect of the feature that we need and add it to the new part of the feature that we need and like do that thing that we need it to do."

Are you ready for this? And this is the key part. The key part is here to be able to say:

"WELL ACTUALLY, I COULD WRITE OUT WHAT THE TECHNICAL REQUIREMENTS ARE TO DO THAT."

Well actually, I could write out what the technical requirements are to do that. Well actually, I could write out what the technical requirements are to do that. Well actually, I could write out what the technical requirements are to do that. Well actually, I could write out what the technical requirements are to do that. Well actually, I could write out what the technical requirements are to do that. Well actually, I could write out what the technical requirements are to do that. Well actually, I could write out what the technical requirements are to do that. Over and over, honey. Over and over again.

Breaking up that kind of human request into what needs to happen in the code

Breaking up that kind of human request into what needs to happen in the code.

Breaking up that kind of human request into what needs to happen in the code... 

... and just like identify which parts of the system need to change.

In order to like...

... fulfil this product feature or engineering challenge.

And that's designing the solution...

... to the feature.

Architecting the solution. It's like going: "Oh okay... there's the feature.... I need to do all of these, like, bits."

Or like someone else going to me:

"Here's a feature request... unfortunately I don't quite know what it means in terms of what your team's app does."

So someone could come to me and request the feature... 

AND THIS GOAL WOULD BE

BREAKING UP THE FEATURE

And going:

Okay, yes.

"THIS IS HOW I DO THIS."

"AND THIS IS HOW I DO THIS."

So it's getting a problem and handling it/analysing it. And final note.

A final little note and this one is on testing:

I shouldn't be told that I need to add in a test. It's just so obvious isn't it. It's part of the other related goal anyway isn't it thanks.