Dziwna sytuacja w nowej pracy i stres

Dziwna sytuacja w nowej pracy i stres
ZT
ZT
  • Rejestracja:około 6 lat
  • Ostatnio:ponad 2 lata
  • Postów:102
3

Kiedyś na linkedin ktoś wysrał post, że programiści oprócz analizy od A do Z powinni jeszcze wymyślać nowe funkcjonalności i proponować je klientom, zostawiając PMowi tylko wycenę. Mam wrażenie, że niektórym tutaj ten pomysł by się spodobał.

Zobacz pozostałe 5 komentarzy
Charles_Ray
PM ma wyceniać? Ciekawe
PerlMonk
Kogoś, kto oczekuje od programisty kompletnego projektu, wyceny itp. zwyczajnie bym wyśmiał dupą. W budownictwie mamy projektanta, operatora koparki, ludzi układających cegły itp. Gdybym ja spytał jak zaprojektować dom Cześka, Mietka, Saszę i Dimę, tobym miał szesnaście koncepcji każdego z pokoi. Może lepiej niech oni zajmą się układaniem cegieł, bo to umieją dobrze. Osoba, która spędza sporo czasu na projektowaniu aplikacji, to nie tyle programista, co człowiek- orkiestra.
Uśpiony wiosenny but
@KamilAdam: może miał na mysli, refaktorowac obecne g**no w kodzie, z czym bym sie zgodzil
KamilAdam
@Uśpiony wiosenny but: niezamawiany refactor jest OK aż do momentu gdy nie okaże się że spowodował dodatkowe issue na produkcji :P
ND
  • Rejestracja:ponad 4 lata
  • Ostatnio:około miesiąc
  • Postów:8
2

Bardzo ciekawy wątek 🙂 Od siebie dodam, że najkrócej ujmując wszystkie wypowiedzi - chodzi po prostu o zdrowy rozsądek. Czy na nieprecyzyjne wymagania na poziomie „chcę ładną łazienkę” powinno się stawać na głowie aby coś zrobić dla samego faktu roboty? Oczywiście, że nie. Czy powinno się arogancko olać temat odpowiadając „za mało szczegółów”? Oczywiście, że nie. Należy zachować balans w relacji i w dobrej wierze najlepiej jak umiemy pomóc tej drugiej stronie. Jako programista, specjalista techniczny, zamiast odpisać „za mało szczegółów” można zadać konkretne pytania / wskazać pkt które są istotne jako wsad. Jako taki PO, widząc że coś chyba jest nie tak, bo niewiele się dzieje, też jako laik mógłby się zapytać „Czy wszystko ok? Może czegoś brakuje i mogę pomóc?”.

Z ogólnego opisu OPa można by wywnioskować że tak na prawdę to nikt tam nie stawia sobie żadnej poprzeczki profesjonalizmu i porusza się skrajnościami. „Biznes” rzucając trzy słowa „tytułu” potrzeby i nie posiadający czasu aby po prostu temat przegadać. „IT” nie wspierające tego „biznesu” jako spece w tym aby sensownie wymagania zebrać 🤷‍♂️

piotrpo
Masz rację w tym co piszesz. Chociaż jestem aktualnie na etapie planowania remontu łazienki i moje wymagania były dokładnie tak jak napisałeś "chcę ładną łazienkę z toaletą, umywalką, prysznicem i miejscem na pralkę 60x60" to okazały się wystarczające do tego, żeby zrobić projekt, który mnie satysfakcjonuje (z bardzo drobnymi poprawkami).
ND
@piotrpo: Jestem w stanie sobie to wyobrazić, to jest jakaś wypadkowa doświadczenia / seniority, natomiast jest całe spektrum, od przygotowania satysfakcjonującego projektu na bazie szczątkowych informacji, przez pytania doprecyzowujące, po właściwe skomunikowanie / poprowadzenie w procesie z delegacją do odpowiednich osób / miejsc aby bez przeszkód taki projekt powstał 🙂 Ot po prostu, zdrowy rozsądek - albo jestem w stanie samodzielnie pomóc drugiej osobie, albo jestem w stanie wskazać właściwą ścieżkę/osobę do popchnięcia sprawy dalej, zamiast „jak grochem o ścianę” 🙂
piotrpo
Spoko, ja rozumiem. Po prostu moje wymagania i oczekiwania były takie jak opisałem, bo założyłem, że ktoś, kto robi takie projekty zawodowo wykona swoją pracę lepiej, na podstawie bardzo luźnych kryteriów. Dalej oczywiście nastąpił proces refinementu wymagań i pytania typu "beże, czy szarości", "okrągłe, czy kanciate", "chrom, złoto, czy czarne". Czyli z grubsza tak jak to wygląda w procesie uszczegóławiania wymagań dla oprogramowania. Całość też nie skończyłaby się dobrze, gdyby codziennie odpisywali "za mało szczegółowe requirementy"
ND
@piotrpo: Piękny przykład! 🙌
Patryk Mieleszko
  • Rejestracja:około 4 lata
  • Ostatnio:około 3 lata
  • Postów:69
2

Biznes często tak robi bo: dev się nie szanuje. Dev jest tańszy niż człowiek z biznesu (często siedzący w centrali w drogim i bogatym świecie) więc taniej jest rzucić devowi ochłap i niech on już tam rozwiązuje za te swoje 200PLN/h.

HA
  • Rejestracja:około 6 lat
  • Ostatnio:około 3 godziny
  • Postów:1006
10

Kiedyś byłem w takiej sytuacji. Firma nie radziła sobie z projektem własnymi siłami i jak to korpo - jest problem to znaczy, że brakuje zasobów. Na szybko zatrudnili kupę "konsultantów", w tym mnie do odblokowania projektu. Tak jak u Ciebie nikt nic nie wie, nowi ludzie rzuceni w otchłań, zero wiedzy biznesowej etc - jedynie deadliny były dość konkretne. Opcje masz 2 albo uciekać albo coś z tym zrobić.

Jeśli zdecydujesz się na tą drugą opcję to po pierwsze musisz być mega asertywny i zacząć od innych ludzi wymagać. Macie SM - to przecież człowiek od rozwiązywania takich sytuacji. Opisz mu cała sytuację i poproś o zorganizowanie spotkania. Oznacz sytuację w Jirze jako blocker z szerokim komentarzem co się musi wydarzyć aby odblokować task, jakie działania podjemujesz, jaki to ma impakt na timeline. Jesteś po prostu w takiej sytuacji, że osoby z wiedzą są w deficycie i reagują na tych, którzy najwięcej krzyczą.

Będąc w podobnej sytuacji zorganizowałem spotkanie wszystkich developerów (w sumie to było kilka teamów pracujących nad produktem), PM'ów i kierownika działu, żeby przedstawić problem, bo miałem wrażenie, że tam każdy mówi co innego. Wypunktowałem wszystko na liście, przedstawiłem rzeczywisty przebieg projektu w różnych zespołach, jakie są blokady, zrobiłem coś a'la wykres Ganta, gdzie każdy z subprojektów podzieliłem na fazy i potem z każdego teamu poprosiłem developerów o umiejscowienie swojego projektu na tym wykresie i wyjaśnienie czemu są tam gdzie są i czego brakuje.

Sytuacja była o tyle zabawna, że projekty były gdzieś tam w 10-15% gotowe, a zarząd uważał, że jesteśmy gdzieś na 75%. Najzabawniejsze było w tym wszystkim, że deweloperzy byli święcie przekonani, że góra wie o problemach i ogólnej fazie realizacji projektu "bo mówili".

Jak się w firmie zorientowano w jakiej czarnej d...ie jesteśmy z projektem to przez tydzień był straszny dym, ale potem wiele tematów się odblokowało i przez miesiąc prace ruszyły z kopyta. U mnie skończyło się tak, że zamiast kodować zostałem de facto PM'em, co chwila jakieś spotkania, odblokowywanie tematów nawet jakieś spotkania z zarządem wpadły. Trochę to było męczące bo development był w godzinach polskich, a devops i biznes w amerykański i trzeba było jeszcze hindusów wpleść, więc się działo. Finalnie jednak fajnie wyszło i dość ciekawe doświadczenie jak można odblokować projekt.

Oczywiście problemy nadal były bo jak to w korpo wszystko musi być pod górkę, ale przynajmniej wiem, że jak już mi się kodowanie znudzi to się w korpo odnajdę. Z firmy finalnie odszedłem (dłuższa historia, trafiłem tam trochę z przypadku i kontraktownia trochę nie dowiozła tego co obiecała), ale tak jak pisałem warto spróbować to dla sportu zrobić, a jak to nic nie da albo po prostu czujesz, że to nie Twoja bajka to uciekać.

I taki jeszcze jeden pro tip - musisz mocno uważać aby nikogo personalnie nie urazić. Jak ktoś nawala (np. PO nie przekazuje informacji na czas) to podkreślaj, że wiesz jak bardzo jest zajęty i proponuj aby firma dała mu kogoś do pomocy. Jak koledzy z zespołu sobie nie radzą, to mów, że macie zespół niedostosowany specjalizacjami i warto byłoby zrobić kilka przesunięć itd itp. W skrócie jak mówisz o kimś dobrze to z imienia, a jak źle to mówisz o problemie nie o osobie. Staraj się wymusić jakieś zobowiązania - np. codziennie 30 minut PO o stałej godzinie na spotkanie z zespołem etc.

BTW - w tej historii ludzie chwalą Hindusa a ja mam jeszcze większy szacun dla SM. Koleś bierze kasę kilka razy większą od Hindusa za wrzucenie daily do kalendarza.

piotrpo
Pod tym względem, to do SM naprawdę mam wyjątkowy szacunek. Jeszcze na początku coś tam z tym daily zrobią, ale dość szybko dochodzą do momentu, ze oni tylko kołczują, a to zespół powinien sobie organizować pracę.
Aventus
Bardzo dobre porady.
Patryk Mieleszko
  • Rejestracja:około 4 lata
  • Ostatnio:około 3 lata
  • Postów:69
0

Na szybko zatrudnili kupę "konsultantów", w tym mnie do odblokowania projektu. Tak jak u Ciebie nikt nic nie wie, nowi ludzie rzuceni w otchłań, zero wiedzy biznesowej

Takie rzeczy da się wyniuchać na etapie rozmowy przedwstępnej.

edytowany 1x, ostatnio: Patryk Mieleszko
HA
W moim przypadku ten projekt to nie był projekt do jakiego mnie zatrudniono, ale ten pierwotny nie wypalił i to było wyjście awaryjne kontraktowni niby na kilka miesięcy. Produkt nie wpisywał się w moją ścieżkę rozwoju (ja chcę iść w big commerce, a to była zwykła apka użytkowa), więc odszedłem jak się okazało, ze z wyjścia tymczasowego zrobił się projekt na lata. Ale w sumie całej przygody źle nie wspominam i zawsze kilka nowych kontaktów wpadło.
piotrpo
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 21 godzin
  • Postów:3277
6

Dodam trochę do tego co napisał @hadwao
W typowym korpo nie ma większej groźby niż zadanie pytania "czy potrzebujesz jakiejś pomocy?". Dla każdego z odrobiną zdrowego rozsądku/doświadczenia przekaz jest jasny - czekam na to co zrobisz, jak faktycznie z czymś utknąłeś, to ci pomogę, ale bardziej prawdopodobne, że jednak zwyczajnie się opierdalasz i twój manager, albo jego manager jak zaczną rozwiązywać problem, którego nie znają, tak ci dowalą swoimi pomysłami, że może jednak znajdź te 30 minut i zrób, zamiast bujać sie z tą pomocną dłonią przez najbliższe 6 miesięcy.

Co do podejścia "ja jestem od pisania kodu" - kompletnie się z nim nie zgadzam. Software developer jest od tworzenia produktu w postaci jakiejś aplikacji, lub usługi. Nie chodzi mi o bycie szwajcarskim scyzorykiem, ale kompletnie pasywne podejście "napiszą coś co zrozumiem, to ja napiszę kod" jest szkodliwe dla projektu, produktu i samego programisty. W innych wątkach są tutaj dyskusje "kim jest senior" i "po ilu latach można zostać seniorem". Moim zdaniem, przejęcie odpowiedzialności za sukces projektu jest jedną z podstawowych cech takiej osoby w moim rozumieniu. Nie chodzi tylko i wyłącznie o jakość kodu, ale rozumienie podstawowych wymagań biznesowych, dostrzeganie problemów w projekcie i aktywne ich rozwiązywanie. To nie oznacza, że mam być kozłem ofiarnym, jak coś nie pójdzie, ale jeżeli widzę jakiś problem, to nie tylko powiem o nim koledze/przełożonemu, ale również zaproponuję rozwiązanie jakie widzę, albo zrobię Rejtana w momencie kiedy jakaś potencjalna zmiana według mnie rozwali pracę.

IT
  • Rejestracja:około 7 lat
  • Ostatnio:ponad rok
  • Postów:261
1

Od tworzenia produktu jest zespół deweloperski w skład którego wchodzi deweloper, grafik, analityk, tester i jakiś owner/lead.
Możliwe, że jedna osoba ma kilka ról ale wtedy to jest ustalone w umowie/ofercie.

edytowany 1x, ostatnio: itsme
ND
Jeżeli to „zespół deweloperski”, to czemu wymieniasz w nim tylko jednego dewelopera? 🤔
HA
W scrum każdy człowiek w zespole jest developerem.
ND
To chyba poprawniej by było powiedzieć zespół scrum jeżeli wyróżniamy dev,grafik,tester itd.? :) Anyway, chciałem się upewnić co autor miał na myśli
piotrpo
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 21 godzin
  • Postów:3277
3

@itsme: Jasne, że za produkt odpowiada "zespół projektowy". Mało istotne jaki ma skład, czy są tam wydzielone role, hierarchia, czy wręcz przeciwnie - płasko i płynny przydział obowiązków.
Ten zespół składa się z ludzi współdzielących odpowiedzialność za ostateczny kształt produktu. Jeżeli jako programista napiszesz super kod, ale on nie będzie robił tego co oczekuje klient, to produkt będzie kiepski, więc jak widzisz ze swojej perspektywy, że coś nie ma sensu, to również twoim obowiązkiem jest to wyciągnąć na wierzch, a jak widzisz lepsze rozwiązanie to powinieneś o tym informować resztę zespołu, zaczynając od osoby, która za to odpowiada w pierwszej kolejności.

Jest też drugi, osobisty powód dla którego warto wyjść trochę poza własną kuwetę. Możesz być świetnym programistą, ale zarabiać mniej niż taki trochę mniej dobry, ale widzący projekt szerzej niż przez okno IDE. W dodatku praca nad czymś, co rozumiesz, widzisz potencjalną wartość, jaką to przyniesie klientowi, albo rozumiesz jaki problem to rozwiąże jest dużo przyjemniejsza i dająca dużo więcej satysfakcji.

Zobacz pozostałe 14 komentarzy
O2
W zdrowym projekcie nie ma żadnego wróżenia z fusów. W zdrowym projekcie wiadomo jaki system piszesz, co on ma robić, chociaż mniej więcej, nie mówię o szczegółach totalnych, ale ogólny zarys musi być. Do czego apka, co ma robić. Czy to ma być sklep, czy portal aukcyjny, czy bankowość.
HA
@omenomn2: jedyny typ projektów w jakim znane są wymagania to jakieś popierdółki i ewentualnie jakieś systemy krytyczne. W zwykłych aplikacjach biznesowych średniej i dużej skali nigdy nie wiadomo do końca co i jak i dlatego wymyślono techniki iteracyjne. Człowiek, który umie w takim projekcie pociągnąć zespół, rozmawiać z decydentami etc tak jak pisze @piotrpo jest za to odpowiednio opłacany + moim zdaniem ma znacznie ciekawszą pracę niż zwykły koder. To jest po prostu kwestia nastawienia.
piotrpo
@omenomn2: Jasne, ale nawet jak wiesz co ma być robione, to nie wiesz jaka część tych założeń się utrzyma przez rok, co wprowadzi konkurencja itd. Nie piszę też o ficzerach zdefiniowanych jednym zdaniem, którego nie da się wziąć. Jasne, ze to patologia. Ale jako członek zespołu, który wie po co pisze ten kod i ma jakieś doświadczenie zawodowe masz też odpowiedzialność za zmianę tej patologii poprzez np. zażądanie refinementów, na których historyjki nabiorą sensownego kształtu.
Charles_Ray
Poza tym w jakiś sposób produkt/biznes musi wiedzieć, co jest technicznie wykonalne, jakie są ograniczenia mające impakt na użytkownika, wreszcie jak sensownie podzielić projekt na iteracje. I nie powiedziałbym, ze „od tego jest tech lead”, bo w tym powinien partycypować cały team, który potem weźmie za to odpowiedzialność. O rany, 3 na 1, wylogowuje się ;)
O2
Napiszemy projekt, ale co ma robić, okaże się później... Nie no spoko, co kto lubi, heh.
ME
ME
  • Rejestracja:ponad 5 lat
  • Ostatnio:prawie 2 lata
  • Postów:168
0

W zamierzchłej przeszłości pracowałem z agencjami digitalowymi. Ludzie od produktu nie mieli pojęcia o swojej robocie więc przerzucali tematy na zespoły. Na spotkania paliliśmy długie godziny, dnie albo tygodnie. Efekty takich działań były takie, że żadne. Raz kiedyś udało się odnaleźć przysłowiowego Graala. Taką januszerkę odwalało się dwie dekady temu. Wtedy wszyscy robili wszystko, a jedyną słuszną metodą pracy był pożar w burdelu.

O tworzeniu produktów / projektowaniu usług popełniono trochę książek, opisano liczne przykłady, opracowano procesy, powstały dobre praktyki. Jak dla mnie
to pewna dyscyplina wiedzy która ma swoje miejsce w obszarze marketingu, zajęcie na full time job, a na pewno nie coś czym można zająć się przy okazji.

Product owner generuje rozmaite tematy oraz dostarcza wymagania. Oczywiście wymagania mogą być takie albo inne. W tym rola zespołu aby wypracować konsensus. Product owner umówił się z managementem na jakieś kpi, na poprawienie tego czy tamtego, na dowiezienie pewnych rzeczy albo wycofanie jakiegoś złomu więc siłą rzeczy jest dysponentem czasu programistów. Oczywiście programista może złożyć nieformalny wniosek aby zająć się tym czy tamtym niemniej to prawo, a nie obowiązek. .

Uruchomienie jiry, utworzenie ticketa, wpisanie tytułu oraz uzupełnienie treści które bardzo często zaczyna się od "As a member of (...) team I'd like to have (...)" z kilkoma bullet pointami niewiele kosztuje, a nadaje sprawie jakiś wymiar formalny. Potem każdy może do tego wrócić, uzupełnić, skomentować.

Rozumiem, że jak ktoś jest nowy to nalezy mu czy jej pomóc, podpowiedzieć, zasugerować i dać takie osobie góra kwartał na ogarnięcie się. Rozumiem, że po stronie klienta jest osoba którą siłą wcielono w taką rolę, nie za bardzo się orientuje to też trzeba pomóc. Natomiast w pozostałych przypadkach to lepiej uciekać z takiego projektu zanim dojdzie do aktów sprawiedliwości ludowej.

edytowany 6x, ostatnio: mealtdown
Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)